Hi,
> I am new to FreeDOS and would like to ask for any helpful hint how
> to create an modified ISO image from the actual FreeDOS version 1.2.
> My "aim" is simple - based on the FD12LGCY.iso image to create a
> bootable DOS ISO image with BIOS firmware upgrade software (DOS based).
creating a
> Yesterday I tagged and released the first beta test of DOS Frotz 2.50.
> Most of the work that went into the DOS interface focus on improving
> stablity. I think I've corrected the two outstanding problems with DOS
> Frotz: locking up upon exit and crashing with a "dos mem corrupt" error.
>
> Have you noticed that move, copy & xcopy refuse
> to work on files bigger than 3 meg.
No. And it's extremely unlikely that copy & xcopy fail in similar
ways (they are entirely unrelated).
> I tried to relocate
> an mp4 file and they all said "out of memory" or
> was it "disk space";
it would
Hallo Herr Dale E Sterner,
am Dienstag, 12. November 2019 um 17:38 schrieben Sie:
> I tried to move post.mp4 - a 3.5.meg file. - got insufficient memory
> error with move, copy & xcopy. The copy command sometimes
> has trouble with wildcard "*". I tried copy *.* new\*.*
the correct command would
> copy on MS-DOS wasn't really meant for copying more than one file
> at a time
bullshit. COPY can copy multiple files. both on MSDOS and FreeDOS.
> (which is why xcopy exists),
no. XCOPY /S is one of the reasons for it's existence. multiple files
not.
Tom
__
>I have 2gigs of drive space used. It seems that move for
>some reason thinks the drive is full.
>
>
>I tried the copy command today and it worked. I don't understand it.
as said before: unless you tell us the exact command that failed, you are just
producing noise.
COPY *.* NEW
will work.
Hallo Herr Felix Miata,
am Donnerstag, 14. November 2019 um 17:38 schrieben Sie:
> Jerome Shidel composed on 2019-11-14 10:27 (UTC-0500):
>> I’m just looking to do quick poll on you thoughts and opinion.
>> When FreeDOS 1.3 is booted as a Live environment from the CD-ROM, should it
>> be permi
>> After you booted DOS from CD:
>>
>> - insert floppy
>> - type "format a:/s"
>> - ...done. You've got "FreeDOS LiveFloppy". You can then transfer needed
>> programs/data to that floppy
> What to do if I don't have a physical floppy or physical floppy drive
> anywhere? (so can't do it "format a
Hallo Herr Ralf Quint,
am Montag, 25. November 2019 um 18:43 schrieben Sie:
> On 11/25/2019 8:36 AM, TK Chia wrote:
>>> One problem here is what I mentioned a lot of times in the past but
>>> always got scoffed at is that these are highly technical apps but do not
>>> have any proper technical do
> MODE COM1:BAUD=9600 DATA=8 STOP=1 PARITY=N DTR=OFF RTS=OFF
MODE (for anyDOS) does nothing sensible about DTR/RTS.
(it might set the status line outputs, I don't know.
there is no way to change the input of status line behaviour.
> I suspect that DTR/RTS being on is the reason why I cannot wri
Hi!
ECHO TEST>COM1
>>> good idea. unfortunately this only works with proper
>>> DTR/CTS/RTS/... status lines connected.
> Unless you select a no-handshake mode.
MODE might be able to suggest to a partner 'I am ready to receive'.
there is no such thing ( for MODE) as 'ignore status lines. s
Hi Frank,
> So in that context, in the Debian-based host OS, I've tried sniffing
> the traffic coming out of tap0 with tcpdump. And, I'm seeing
> something interesting.
> In perfect correlation with the DOS guest's DHCP client starting up,
> I can see a "packet of all zeroes" every now and then
>> in short: when debugging network problems, avoid EMM386/JEMMEX.
>>
>> HIMEM and friends should be fine, though.
>>
> Okay, I'll try to figure out my way through this...
> I definitely do need something to load all the resident drivers
> "high" wherever possible, otherwise I'm out of conven
Hallo Herr Jack Browning,
am Montag, 6. Januar 2020 um 19:32 schrieben Sie:
> I've been trying to update the BIOS on my wife's Dell Inspiron 17
> 5721 laptop using FreeDOS. I've tried to do this with FreeDOS 1.0,
> 1.1, 1.2, and 1.3rc2, each time with the same result.
> What happens is this: af
> MS DOS 6.x was not the end of MS-DOS. Windows 9x releases added a
> strange protected mode, but unlike NT, these versions of Windows still ran on
> top of MS-DOS.
> There is no support for DOS based Windows any longer and the
> ReactOS project essentially abandoned it. However, there are
> em
> I've starting working on a game and some small dual monitor (VGA +
> MDA) utilities but have run into issues where the code used to work
> and now it doesn't. We use subversion, cvs, and git at work and I
> was wondering what options are available for dos-based systems besides dated
> zip fil
> On 16/02/2020 22:54, tom ehlert wrote:
>> doing programming *on* DOS in 2020 is just stupid.
> Why would that be more stupid than programming *for* DOS in 2020?
> A hobby is a hobby.
ok. replace 'stupid' by 'inefficient' in the sense that there are
easier w
to do with the PCI bus.
> The only format I have achieved is with a Teac USB floppy drive in
> Windows Millenium, the ISA card not installed at all.
> Can someone shed light some light on Error 136 and DMA troubles?
Hallo Herr FreeDOS.,
Mit freundlichen Grüßen / with kind regar
> Regrettably, I ran into another problem: apparently the CD I burned was
> roughed up too badly for the installation to complete. It died while
> trying to install UDVD2, due to a read error. And that was my last
> CD-R.
as you don't describe in detail what you did we can only guess :<<
most
> I'm working with an EVOC brand SBC on a PICMG 1.0 backplane.
> I have not been able to get floppy disk support in Freedos 1.3, period.
as far as I understand it, you have been working with MSDOS 6.x for
the last 25 years.
I recommend another 20 years.
the alternative would have been to
a)
> What he is looking for is a TSR which provides x87 emulation ...
right
> Best chance would probably is if any author of the EMM386 versions
> around here could comment and eventually work with him together to
> fix any incompatibilities...
as the original author:
goto EBAY, spend ~10 USD for rea
Hallo Herr Lee Eric,
am 17. März 2011 um 15:21 schrieben Sie:
> Hi,
> I download UIDE driver and try to make it work but when system boots
> it will hang when UIDE driver loads. Here's AUTOEXEC.BAT contents:
> @echo off
> SET dosdir=C:\FDOS
> REM C:\FDOS\BIN\BANNER2
> REM C:\FDOS\BIN\BLACKOUT
Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos
> See HP, Dell, Asus, etc. They all happen to ship FreeDOS on their systems.
See HP, Dell, Asus, and you will learn quickly that FreeDOS is a
synonym for 'without operating system', intended for people that
install their own OS (which is most likely NOT FreeDOS)
> On Sun, Jun 5, 2011 at 10:
> The basic problem is that INT 15.4F is a BIOS function that can be
> called by any program at any time.
completely wrong.
int 15.4f is supposed to be called from the BIOS from the
INT 09 handler, and NOBODY else.
> It's true that it is always
> supposed to be called by the INT 09 handler (thou
> We (well, at least I) have a severe dilemma going on here.
let's call it 'disagreement'
>> int 15.4f is supposed to be called from the BIOS from the INT 09
>> handler, and NOBODY else.
> Obviously, MS believes that INT 15.4F can be called from outside
> INT 09, based on what they've published o
> Particularly in the case of USB, where the USB keyboard may be the
> only one the computer has, simulation at the scancode level is the
> only viable option. Simulation at the BDA level would almost be pointless.
use the 8042 keyboard controller command 0xd2 to simulate scancode
received.
that's
>> use the 8042 keyboard controller command 0xd2 to simulate scancode
>> received. that's documented (again in the IBM technical reference)
>>
>> this will simulate a scancode all the way through interrupt handler,
>> int15.4f, ...
> That is exactly what I call "Method 1" does. The problem is,
>> are you sure 200 is enough ?
>>
>> this should *ALWAYS* succeed, so IMHO it might be worth trying 0x
>> instead. (and you nowhere log if this test fails)
>>
>> I can also imagine some situations where CLI might hurt ('flaky').
>> in particular if some data are still in the keyboard receive
> I personally think that the invention of
> INT 15.4F was a mistake, though I'm sure IBM thought it was a really good
> idea, at least at the time.
I personally think that the invention of
INT 15.4F was a fantastic idea; actually it was really necessary.
DOS is supposed to use the BIOS for all
Hi Eduardo,
> I'm pleased to announce the availability of the first version of
> VMSMOUNT, an installable file system for DOS that allows access to
> VMware's shared folders as a normal drive letter:
it simply woks as advertised
it doesn't leave unused clutter loaded as TSR
---
Hi Eduardo,
sorry; pressed the send key too early ;)
> I'm pleased to announce the availability of the first version of
> VMSMOUNT, an installable file system for DOS that allows access to
> VMware's shared folders as a normal drive letter:
it simply works as advertised
it doesn't leave unuse
> Yes, only there, which can be easily solved doing a couple of "pop bx"
> instead of the "pop gs" and "pop fs". The only other 386 specific code
> is in the VMWARE interface.
"push gs" and "push fs" are issued by the keyword "interrupt" and
compiling with 386 optimization.
compiling without 386
Eduardo,
bug ro feature ? I don't see any files with long filenames.
Shouldn't they be visible with their short filenames
filena~1.exe
Tom
--
All the data continuously generated in your IT infrastructure contains a
Hi
> I was wondering how secure is FreeDOS on a network.
FreeDOS has no network, so it is complete secure ;)
anything else is application specific.
> Does it have a
> security policy, eg do I have to run a firewall TSR, etc..?
> How are updates delivered, eg by reinstalling over the directory?
Hi,
> THE HELP-COMMAND SCREEN FILE HAS IMPROVED WELL.
> BUT IT STILL NEEDS ONE THING:
> UNDER THE TOPIC "SHELL" AND "SHELLHIGH",
> THE SWITCHES
> /F and
> /MSG
> NEED TO BE DOCUMENTED,
> SO PEOPLE DON'T HAVE TO FIDDLE WITH THE SWITCHES TO SEE HOW THEY WORK.
both are related to the non-XMS-swappi
h
CX = call mask (see #03171)
ES:DX -> FAR routine (see #03172)
you should terminate with
CX=0
Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886
--
Keep Your Developer Skills Cu
> 1). I wouldn't use the PIT, sounds unreliable,
using the PIT can be made reliable; has worked flawless for over 20
years since some 80286
> but then again, I don't know how anyways. ;-)
> 3). RDTSC (586+) is probably not what you want, esp. due to early
> 586-686 time duration limitations an
more details here
http://www.h-online.com/open/news/item/VFat-patent-could-be-invalidated-thanks-to-Motorola-and-Torvalds-1486484.html
Tom
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Her
>>With a help of Ed (DXForth creator) the problem is recognized; Ed wrote:
>>
>>#v+
>> 4DOS (or something associated with it) is setting PIT timer 0
>> from mode 3 to
>> mode 2 - which in turn is causing MS in DX-Forth to run slow.
>>#v-
> Nice find, didn't really expect that. Any hints in the
T
/T is probably an option
DATE\T
probably some program in subdirectory DATE shall be executed
> P.S. On the contrary: to 4DOS could be added "line completion", which
> works nicely in FreeCon.
nobody's perfect ;)
Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886
--
11. April 2012 um 21:23, dmccunney wrote
> Current machines won't *boot* DOS, but will *run* it in a
> compatibility box, emulator or virtual machine.
I wonder what you are talking about.
current machines *do* boot DOS, and mosty likely will continue to do
so for the foreseeable future.
> If
Hi!
>> howto says to edit autoexec.bat changing the line "REM LH PCNTPK
>> INT=0x60" to "LH PCNTPK INT=0x60". This didn't work for me.
please take the time and report the drivers error message.
if needed place a
PAUSE
command below the
LH PCNTPK INT=0x60
line.
this could be a problem between
> I recently put FreeDOS on my laptop that has built in wireless. I tried to
> see if the BIOS on the computer would let me know what the packet driver
> name was or where, but it didn't. So I was wondering how to find it or how
> to scan for what type of driver to get, or something. I tried just
>> I was about to post bugreport at VirtualBox bugtracker, but decided to
>> double-check the issue first. On my system floppy images change are
>> correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1.
> The "issue" is that VirtualBox is not posting diskette media-change
> status in the
Jack,
>>> The "issue" is that VirtualBox is not posting diskette media-change
>>> status in the BIOS data table.
>>
>> the 'issue' is that VirtualBox clearly states
>> 'floppy without change-line support'
>>
>> int13/15 returns '01h floppy without change-line support
>> int13/16 returns '06h cha
Jack,
>>> UIDE has NEVER ignored if a diskette has change-line support! It
>>> does in fact check the BIOS data table at 0:448h for bit 0 (change
>>> line for diskette A:) or bit 4 (change line for diskette B:). If
>>> those bits are off, diskette A: or diskette B: will not be cached.
>>
>> i
> Given how UIDE/UIDE2's diskette I-O has never been a problem BUT
> for VirtualBox, I will keep UIDE/UIDE2 as-is.
this is going nowhere. Jack is right and everybody else is a bloody
idiot.
AMEN
Tom
--
Live Security
Hallo Herr Jim Hall,
am 25. Mai 2012 um 00:06 schrieben Sie:
>>> Use UIDE/UIDE2 if you think they work. Otherwise, do not use them.
>>
>> The third choice is giving my "prosthetic" helper a try ;-) Users
>> of VirtualBox and UIDE, but also of other systems including real
>> hardware, are invited
> Jack, Bret, VirtualBox users,
>> A favorite tactic of "propagandists", be they Fascist/Nazi/Communist
>> or others, is that they flatly IGNORE any information from opponents
> At this point, you lost the discussion and many readers will
> simply have skipped the rest of your mail, as explained
Hi Marcos ,
>> So where exactly is the file server that's storing the data
>> file(s) in this scenario? Is it on the doctor's PC, assistant's
>> PC, or some other location?
> In another location.
could you be more specific about
1) where is the database located (not geografically, but what ma
> I remember databases benefitting from a high amount of file handles,
not 'benefit'. for some problems, many handles are needed, otherwise
the database will not work at all.
there is NEVER spurious problems caused by too many handles.
> but likely that's already being taken care of by caching so
> I'm running FreeDOS, but yes, Linux is a possibility. This
> database project started modestly in 2006, but now the Health
> Center is relying more and more on it, so I want it to be very
> safe.
in that case don't gamble with untested share.exe
> Still I would definitely prefer to stay with Fre
> Tom Ehlert wrote:
>> try using MSDOS or linux (or even Windows) for the
>> 'server' machine, and see if the problema go away
> I did the test with MS-DOS in the server and FreeDOS in the
> client.
> The problem vanished.
> I even used "MODE con rate
>> conclusion: don't use FreeDOS as a 'server' machine.
> Sure, that's the obvious "easy" way out.
> But wouldn't it be better "overall" (and wiser) to 1). actually find
> out what MS-DOS does, and 2). "fix" it in FreeDOS' kernel?;-)
sure. as always: talk is cheap
good luck
Tom
--
> Whatever the issue is, it is apparently not that easy to find or
> fix.
whatever the issue is, nobody is going to fix it anyway
> Reading RBIL for INT 21.5C, it seem to indicate that DR-DOS
> never was able to figure out how to do it, and it wasn't until
> Novell got involved that it actually s
>> On Mon, Jun 18, 2012 at 6:25 AM, Tom Ehlert wrote:
>>> conclusion: don't use FreeDOS as a 'server' machine.
>> Sure, that's the obvious "easy" way out.
>>
>> But wouldn't it be better "overall" (and wiser) to
> I am trying to create a FreeDOS USB stick to flash a BIOS. Using
> UNetbootin I succeeded in installing FreeDOS 1.0 (fdboot.img) on the
> USB stick. I am having a hard time figuring out though how to add
> files to the live session. Since the live session seems to mount the
> floppy image ubnin
Hi,
> We are facing a difficulty with the 'copy' command in the
> network of our Health Center.
> We occasionally need to copy files from the server to the local
> disks of client machines.
> I have been doing these copies by means of file managers such as
> Navigator, NDN or Connect, and it is
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886
---
>> I found somewhere that 4DOS seems to try to lock the files (and
>> fails sometimes). are you using 4DOS as a shell ?
> Yes, 4DOS is the shell both in server and in clients.
searching for 'msdos lock violation', the 2nd entry is
http://comp.os.msdos.4dos.narkive.com/Qbd7ANyv/lock-violation-on
> rufus may be a good solution, but given that it runs on windows
> only, it's definitely not a silver bullet.
sure. but given that it's the only bullet ...
Tom
--
LogMeIn Rescue: Anywhere, Anytime Remote support for I
> Hello list:
asking programming errors on a mailing list that is focused on
operating system development is considered BAD.
> I am having Stack Overflow problems with this simple code under FreeDOS and
> OpenWatcom:
> #include
> char a[8192];
> int main()
> {
> int i;
> char b[8192];
> At 12:58 PM 12/20/2012, Louis Santillan wrote:
>>The Memory Model (Tiny vs. Small vs. Compact vs. Medium vs. Large,
>>.COM vs. .EXE) of the compiler could be causing the issue. Some
>>compilers used to default to Small. What compiler flags are you using?
> Even in the TINY model, there is no
>> asking programming errors on a mailing list that is focused on
>> operating system development is considered BAD.
> I don't think we have enough developers (OS or application) or enough
> list traffic where we can afford to be picky ...
this is stillnot the 'programming for dummies' mailing l
> - An editor should be small enough to run on a 128K machine.
FreeDOS will not run on a 128K machine.
> - Calculator? How many people do not have a physical calculator or cell
> phone laying around nearby?
you are right. but wtf will I use a 128K machine for if I have a
iPhone around ?
> - An e
> On 1/29/2013 11:09 AM, Tom Ehlert wrote:
>>> - An editor should be small enough to run on a 128K machine.
>> FreeDOS will not run on a 128K machine.
> Ok. Then make it 256. You get the idea.
> I haven't looked into the source code, but is FreeDOS really that mu
> Get up on the wrong side of the bed today? Why so defensive?
> PC/MS DOS 5.x and 6.x will run in 256K with usable memory to spare.
> PC/MS DOS 3.x will run in 128K with usable memory to spare.
FreeDOS will inherently use ~60K more then MSDOS as command.com swaps
only to XMS or not at all.
> If
> Exactly *where* is the string of characters for the path variable stored?
in the environment which is pointed to by the PSP
http://en.wikipedia.org/wiki/Program_Segment_Prefix
> For that matter, where are stdin/out/and err?
that's like asking 'where is monday'
tom
---
Hallo Herr Louis Santillan,
> https://sites.google.com/site/lpsantil/Home/386DIS.ZIP
> https://sites.google.com/site/lpsantil/Home/686DIS.ZIP
> https://sites.google.com/site/lpsantil/Home/PATCHES.ZIP
> https://sites.google.com/site/lpsantil/Home/kernels.zip
the differenz is an empty memdisk.lst
>> I don't think wcc.exe was ever meant to output 32-bit code. Granted,
>> as mentioned previously, it will do some things ("movsx"), but
>> apparently it doesn't use the extended 32-bit registers.
>>
> That's the most disappointing part. As expensive as Watcom was, I was
> expecting it do this
> Badly written ifdef in memdisk.asm. Fixed such that 486+ compiles. Read (
> ftp://openwatcom.mirrors.pair.com/manuals/current/cguide.pdf) and sections
> 2.3.x & 3.5. Enlightening and disappointing. There does not seem to be a
> way to get 32-bit instructions out of wcc as Tom had mentioned.
bay today. Should be in my
>>> hands in 7-10 days. :D
>>>
>>>
>>> On Tue, May 7, 2013 at 10:45 AM, Louis Santillan wrote:
>>>
>>>> On Mon, May 6, 2013 at 5:46 AM, Tom Ehlert wrote:
>>>>
>>>>>
>>>&g
>>> GPL, so patches welcome! :-)
>>
>> Patch what? This code is so tragically flawed and devoid of purpose
>> that there is nothing worth patching.
> In case it wasn't obvious, 0.0.1 implies that the program is far from
> finalized, perfected, mature, or even release quality. Ever heard of
> "wr
> I fixed some compile time errors and uploaded new version (1.2e) of Hexed
> to my site. This is a DOS and Linux console hex viewer/editor.
> http://digitalatoll.com/pub/DMSOFT/hexed-src-1.2e.zip
> The sourceforge project is at
> http://sourceforge.net/projects/doshexed
'Also, if you find this
> That's funny, because I thought that the master environment was
> controlled by the kernel.sys?
obviously not as it's size is controlled by '/E:512'
> Maybe they can add a switch that
> forces the environment be loaded in upper ram instead of conventional?
'they' could do nearly everything
a
Hi Bertho,
> I've seemed to notice Command.com locates its master environment
> block at the top of conventional memory, just under the video (and
> under a BIOS defined extended bios data aka EBDA, if any).
> Is this behaviour user-controllable with some switch while loading
> FreeCOM ?
what w
>>> I've seemed to notice Command.com locates its master environment
>>> block at the top of conventional memory
>>> Is this behaviour user-controllable with some switch while loading
>>> FreeCOM ?
>> what would be the purpose to change this ? whee would you
>> like to have it ?
>>> Or otherwise,
>>> I'm surprised you have to question this!
>>after ~12 years without anybody complaining, I'm surprised about you
>> complaining.
> How many users do you have ?
I have no idea - and don't care.
> Of these, how many understands this level of detail, /and/ in addition, will
> care ?
answering t
Bertho ???,
>>> Casually peeking at Freecom source, branch MAIN, init.c v 1.31,
> ...
>>> I'm not sure what is to be gained by using 'lastfit' even in upper memory.
> ...
>>> Hoping someone will take the challenge,
>> left as an exercise to the reader. suffice it to say: you wouldn't like the
>>
>> Bertho ???,
> You may call me Czerno, Herr Ehlert
your email signature reads "Bertho Grandpied "
that translates to Bob Bigfoot, right ?
>>> You can't escape having to explain what "adverse effects" you were evoking,
>>> now anyway.
>> command.com is a 'normal' program. just allocating DOS
>> you would end up with
>> 3 K COMMAND.COM, (resident part)
>> 100 K FREE (remainders of freecom before resizing)
>> 1 K command.com environment (at ~1800:0)
> How lame ! Of course, your Freecom shall have to play a minimum game of
> releasing its own initialisation code an
Hi,
> Should OTOH you (and the FreeDOS project at large) wish to offer the
> free XBDA mover as a supplement/alternative to FreeDOS's internal, I'll
> contact you for arranging the mirroring. It's a simple, robust and
> tiny DOS device driver coded in ASM, a few hundred bytes altogether.
it probab
> Thanks. It would work indeed because - as I was checking a few minutes
> before reading your mail - FreeCOM does maintain the master environment
> pointer (its segment) in its PSP:3Ch slot, additionally FreeCOM seems
> to use the contents of that 'slot', not some copy it made, whenever
> it needs
>>> I may sound harsh, but being accused of ignorance by
>>> more ignorant is the only word of excuse I will utter.
>
>> this 'more' makes me think that you should prove your competence
> first
>
> I agree. The above quoted phrase was a late minute, unfortunate
> addition to my mail, that was
>> The problem with tar. files is you must first uncompress the
>> tar file, then extract what you want (and possibly then remove the
>> uncompressed tar file.)
> Not really. If you use tar for decompression (and not 7za) it will
> automatically "pipe" the output of tar to appropriate decompressi
Hi Mateusz,
>> is there a place you can download all of freedos in one big piece,
>> but including all the up-to-date everything?
> As Bojan already pointed out, such place already exists. It's here:
>
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/
this wou
> i made a dos version of this, version 1.0.3.2 , i still have to
> test it out but it getting late linux version seems work okay though.
> it used rle encoder to compress the file and is only effective on
> data that repeats alot, it is in the git repository
Features 'Rle compression'. wow.
doe
for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/
> Also, what are the chances that someone within the FreeDOS community may
> one day write a driver for a filesystem which supports extended
> attributes?
Zero.
for a simple reason: there is no functionality ('API') like
Get/SetExtendedAttributes in DOS; therefore DOS programs can't support
this
> When I run the defrag program on my dos machine, It does not allow me to
> do a full defrag. The options are limited (grayed out).
> On that machine, I am running freedos and for a command processor,
> 4dos. FAT32 was created by a windows o/s before I bought it. I have
> since removed windo
keys,
> whereas we are talking about the other arrow keys here.)
> Because this is a keyboard issue, I (rather vaguely) remember
> trying MKEYB.EXE by Tom Ehlert instead of the standard FreeDOS
> KEYB.EXE, but the problem remained.
> Today, however, for the first time, the same problem happe
> You can download my SCANTEST program
good idea;
MKEYB BR /T
does something similar
> (it's included with the USB drivers)
that gives us the idea to ask:
is this a PS/2 or USB keyboard ?
> Just as another troubleshooting item, does it happen even when you
> don't have a special keyboard dri
Hallo Herr Zbigniew,
am 29. Juni 2014 um 02:35 schrieben Sie:
> 2014-06-29 1:13 GMT+02:00, Rugxulo :
>> Turbo Pascal has a smartlinker while Turbo C does not.
Turbo C linker is about as smart as Turbo Pascal.
> Indeed I noticed even earlier, that OBJ is of "decent size" (just a
> little more th
>> Most probably because you use printf().
> It seems, not too much I can do about this using Turbo C:
> 1. Compilation of "Hello, world!" containing "printf" gave around 370
> bytes for OBJ, and 8.3k for EXE.
> 2. The same when replaced "printf" with "puts" gave 6.4k for EXE.
puts() is essentia
_
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886
--
>>> Want fast and easy access to all
>> the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> sea
>> This is not really about FDNPKG, but more about "how packages are
>> structured". Indeed, I tend to avoid putting to much stuff into
>> %FREEDOS%\BIN, and only put there stuff that is supposed to be part of
>> the FreeDOS "core" (ie BASE, that is similar functionality than what
>> MSDOS was p
>> 'Which means "Accept what the package manager does by default." I
>> mostly concur, but an advanced user might have reasons for wanting
>> things elsewhere. It's nice it the package manager gives them an
>> option to do so and specify where, but if it needs AUTOEXEC.BAT
>> modified for things
Hi Mateusz,
> On 08/15/2014 12:29 PM, Tom Ehlert wrote:
>> a better way to achieve the same effect would be a directory on the
>> PATH with batches that redirect to the proper location.
>>
>> ZIP.BAT
>> shift
>> c:\USR\BIN\ZIP %1 %2 %3 %4 %5 %6 %7
101 - 200 of 455 matches
Mail list logo
