Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
On Fri, 09 Feb 2018 14:47:58 +0100, Bart Oldeman wrote: Hi Matej, can you post your exact config.sys and which kernel.sys you are using? It's a modified version of the default one from FreeDOS 1.1: !DOS=HIGH,UMB !DOSDATA=UMB !LASTDRIVEHIGH=Z !FILESHIGH=40 !MENUCOLOR=7,0 !IDLEHALT=-1 ; (MENU commands skipped) ; Default configuration COUNTRY=038 DEVICE=\DOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST FASTBOOT DEVICEHIGH=\DOS\BIN\SRDXMS.SYS SHELLHIGH=\COMMANDW.COM \DOS\BIN /E:1024 /P=\FDAUTO.BAT however, I get 45 instead of 48 buffers in HMA, so the kernel is likely different (the FD 1.2 kernel I got was 2042, Watcom, FAT32, May 11 2016). Yes, I compiled it myself in 2015. It says it's 2042, but I don't know what has changed since then. But even if you can't fix this, it's no problem for me to just work around it in FDAUTO.BAT. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
On Sun, 04 Feb 2018 22:40:25 +0100, Eric Auer wrote: Hi Matej, 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right after that I see "Not enough memory" ... Are you sure that this does not happen with older FreeCOM? Yes. I think this is still an improvement compared to the previous version (if compiled with OW), but the Turbo C++ version does not have any of these problems. Please explain :-) What I meant is that 0.84-pre2 was even more unstable when compiled with OW (I remember getting "MCB chain is corrupt" errors when using LOADHIGH). 0.84-pre3 is better, but OW support is still lagging behind Turbo C++ in any case. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hi, On Sat, Feb 3, 2018 at 4:44 AM, Bart Oldeman wrote: > > as some of you know I spent some time fixing various bugs in FreeCOM. > > So for testing I uploaded a new prerelease on github: > https://github.com/bartoldeman/freecom/releases/tag/com084pre3 > > There are three non-UPXed xms-swap command.com's in the binary zip, > one compiled with Turbo C++ 1.01 (as the older version were), one > cross-compiled with OW 1.9 and one cross-compiled with ia16-elf-gcc. > Please test and let me know how stable they are in your testing. Unfortunately, under QEMU, it seems none of these work correctly (in my latest MetaDOS image). Maybe it's some side effect of something else or some quirk in my secondary configs somewhere. GCC build bombs out with "Invalid Opcode". OpenWatcom gives some "Out of memory" errors and hangs before I can even do anything else. TurboC++ similarly hangs at end of bootup. I'm willing to try again eventually (of course), but this kind of thing is not exactly obvious on what's going wrong. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hi Bart, > that syntax is unfortunately incompatible with FreeCOM itself and > COMMAND.COM too. I always forget about FreeCOM itself :<< > How about this: my solution would be set AMP=& if "%AMP%" == "" set AMP=^^^& echo %STR% %AMP%>> %FILE% tested on windows only. > as for stack growing down to heap I think the compiler's stack > checking / malloc returning NULL should take care of that.. in theory yes. in praxis only if stack checking is enabled... thanks for taking care of /lfn (and other bugs) Tom -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hi Matej, can you post your exact config.sys and which kernel.sys you are using? I cannot reproduce your issue with a plain FD 1.2 installation in QEMU with this: DOS=UMB,HIGH DEVICE=C:\FDOS\BIN\JEMMEX.EXE SHELLHIGH=C:\COMMANDW.COM DEVICEHIGH=c:\srdxms.sys where srdxms.sys comes from srdsk209c.zip. however, I get 45 instead of 48 buffers in HMA, so the kernel is likely different (the FD 1.2 kernel I got was 2042, Watcom, FAT32, May 11 2016). I have fixed the issue with dir/lfn in the SVN source code now. Bart On 4 February 2018 at 11:38, Matej Horvat wrote: > I found these bugs in the OW version so far: > > 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and > DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel > prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right > after that I see "Not enough memory" (not sure what prints that), and > FreeCOM prints "The shell is about to be terminated, though, this is > forbidden", etc., and hangs. Loading the same driver with DEVLOAD from > FDAUTO.BAT works fine. > > 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's > CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading > the same TSRs manually works fine. > > 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with > other options), FreeCOM prints "Out of memory" instead of the expected long > file names - but "/LFN" by itself works fine. > > I think this is still an improvement compared to the previous version (if > compiled with OW), but the Turbo C++ version does not have any of these > problems. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hallo Herr Tom Ehlert, that syntax is unfortunately incompatible with FreeCOM itself and COMMAND.COM too. How about this: === @echo off set FILE=%1 set STR=+%2 rem read-only environment variable in cmd.exe (ignored there) set CmdExtVersion= :loop shift if "%2" == "" goto end set STR=%STR% +%2 goto loop :end if "%CmdExtVersion%" == "" goto commandcom rem in cmd.exe CmdExtVersion is set to either 1 or 2. echo %STR% ^&>> %FILE% goto theend :commandcom set STR=%STR% & echo %STR%>> %FILE% :theend == as for stack growing down to heap I think the compiler's stack checking / malloc returning NULL should take care of that.. Bart On 5 February 2018 at 10:47, Tom Ehlert wrote: > Hallo Herr Bart Oldeman, > > am 5. Februar 2018 um 11:06 schrieben Sie: > >> Hi Matej, > >> thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN. >> It doesn't happen with the GCC compiled version either. I'll need to >> debug this a bit. >> OW has heap after stack unlike the other compilers, which have stack >> after heap. Stack after heap allows a bit of flexibility as the two >> grow to each other, so perhaps it's just that the heap is too small. > if it's trashing the stack, this should be detected somehow, and > printing some diagnostic message. > > >> I'll let you know. > > for TCPP and Windows, please replace in ECHOLIB.BAT > >... >set STR=%STR% & > >echo %STR%>> %FILE% > by > >echo %STR% ^&>> %FILE% > > > as a standalone '&' has special meaning for Windows CMD and gets eaten > > otherwise TCPP builds out of the box (something that wasn't possible > for ~10 years). compliments. > > Tom > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Tom: You are correct in that it happens with an INSTALL= line in CONFIG.SYS, though I never heard there was a known patch for it. I don't use FreeDOS on a regular basis, so am not sure of the current state of this issue in the official releases. In my case, it wasn't with RAMDISK.EXE that I noticed it, but rather one of my TSR's that needs access to the top part of conventional memory while installing. The problem being discussed here may or may not be related at all, or may be related only indirectly. Warning: Don't Use Probiotics Before You See This gundrymd.com http://thirdpartyoffers.juno.com/TGL3141/5a7b66fac741966fa05a0st01vuc-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hi Bret, > I'm not 100% sure, but this could be (at least indirectly) related > to the issue I discovered several years ago, where FreeCOM uses > memory "illegally" while installing (processing CONFIG.SYS and/or > AUTOEXEC.BAT). That is, FreeCOM uses a lot of memory that's at the > top of conventional memory (just below the 640k point), but doesn't > actually allocate (and thereby "protect") the memory with a Memory > Control Block (MCB). As a result, any program that actually tries > to use that memory will crash the system since it doesn't know that > FreeCOM is already using it. In my case, I was requesting an MCB at > the top of conventional memory, and the kernel issued it to me even > though it shouldn't have because the memory was already being used > (by the kernel). Again, I don't know if this related to the > particular problem Matej is having, but it seems like it could be. IIRC this problem was (is?) a kernel problem, that happens at INSTALL=ramdisk.exe processing (please confirm), not related to FreeCOM. INSTALL= processing is done by Kernel, not FreeCOM. this bug is fixed by moving DoInstall from main.c, line 128 - DoInstall(); kernel(); } to main.c, line 493: } DoInstall(); init_call_p_0(&Config); /* go execute process 0 (the shell) */ } Tom > -- Original Message -- > From: Bart Oldeman > To: "Technical discussion and questions for FreeDOS developers." > > Subject: Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease > Date: Mon, 5 Feb 2018 11:06:06 +0100 > Hi Matej, > thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN. > It doesn't happen with the GCC compiled version either. I'll need to > debug this a bit. > OW has heap after stack unlike the other compilers, which have stack > after heap. Stack after heap allows a bit of flexibility as the two > grow to each other, so perhaps it's just that the heap is too small. > I'll let you know. > Bart > On 4 February 2018 at 17:38, Matej Horvat > wrote: >> I found these bugs in the OW version so far: >> >> 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and >> DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel >> prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right >> after that I see "Not enough memory" (not sure what prints that), and >> FreeCOM prints "The shell is about to be terminated, though, this is >> forbidden", etc., and hangs. Loading the same driver with DEVLOAD from >> FDAUTO.BAT works fine. >> >> 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's >> CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading >> the same TSRs manually works fine. >> >> 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with >> other options), FreeCOM prints "Out of memory" instead of the expected long >> file names - but "/LFN" by itself works fine. >> >> I think this is still an improvement compared to the previous version (if >> compiled with OW), but the Turbo C++ version does not have any of these >> problems. >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > The Unusual Link Between Alzheimer's and Coconut Oil (Watch) > Memory Repair Protocol > http://thirdpartyoffers.juno.com/TGL3142/5a7a161e77d43161e6b53st01vuc Mit freundlichen Grüßen/Kind regards Tom Ehlert +49-241-79886 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
I'm not 100% sure, but this could be (at least indirectly) related to the issue I discovered several years ago, where FreeCOM uses memory "illegally" while installing (processing CONFIG.SYS and/or AUTOEXEC.BAT). That is, FreeCOM uses a lot of memory that's at the top of conventional memory (just below the 640k point), but doesn't actually allocate (and thereby "protect") the memory with a Memory Control Block (MCB). As a result, any program that actually tries to use that memory will crash the system since it doesn't know that FreeCOM is already using it. In my case, I was requesting an MCB at the top of conventional memory, and the kernel issued it to me even though it shouldn't have because the memory was already being used (by the kernel). Again, I don't know if this related to the particular problem Matej is having, but it seems like it could be. -- Original Message -- From: Bart Oldeman To: "Technical discussion and questions for FreeDOS developers." Subject: Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease Date: Mon, 5 Feb 2018 11:06:06 +0100 Hi Matej, thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN. It doesn't happen with the GCC compiled version either. I'll need to debug this a bit. OW has heap after stack unlike the other compilers, which have stack after heap. Stack after heap allows a bit of flexibility as the two grow to each other, so perhaps it's just that the heap is too small. I'll let you know. Bart On 4 February 2018 at 17:38, Matej Horvat wrote: > I found these bugs in the OW version so far: > > 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and > DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel > prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right > after that I see "Not enough memory" (not sure what prints that), and > FreeCOM prints "The shell is about to be terminated, though, this is > forbidden", etc., and hangs. Loading the same driver with DEVLOAD from > FDAUTO.BAT works fine. > > 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's > CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading > the same TSRs manually works fine. > > 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with > other options), FreeCOM prints "Out of memory" instead of the expected long > file names - but "/LFN" by itself works fine. > > I think this is still an improvement compared to the previous version (if > compiled with OW), but the Turbo C++ version does not have any of these > problems. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel The Unusual Link Between Alzheimer's and Coconut Oil (Watch) Memory Repair Protocol http://thirdpartyoffers.juno.com/TGL3141/5a7a161e77d43161e6b53st01vuc-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hallo Herr Bart Oldeman, am 5. Februar 2018 um 11:06 schrieben Sie: > Hi Matej, > thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN. > It doesn't happen with the GCC compiled version either. I'll need to > debug this a bit. > OW has heap after stack unlike the other compilers, which have stack > after heap. Stack after heap allows a bit of flexibility as the two > grow to each other, so perhaps it's just that the heap is too small. if it's trashing the stack, this should be detected somehow, and printing some diagnostic message. > I'll let you know. for TCPP and Windows, please replace in ECHOLIB.BAT ... set STR=%STR% & echo %STR%>> %FILE% by echo %STR% ^&>> %FILE% as a standalone '&' has special meaning for Windows CMD and gets eaten otherwise TCPP builds out of the box (something that wasn't possible for ~10 years). compliments. Tom -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hi Matej, thanks for the feedback. I reproduced the issue with DIRCMD=/OGN/LFN. It doesn't happen with the GCC compiled version either. I'll need to debug this a bit. OW has heap after stack unlike the other compilers, which have stack after heap. Stack after heap allows a bit of flexibility as the two grow to each other, so perhaps it's just that the heap is too small. I'll let you know. Bart On 4 February 2018 at 17:38, Matej Horvat wrote: > I found these bugs in the OW version so far: > > 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and > DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel > prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right > after that I see "Not enough memory" (not sure what prints that), and > FreeCOM prints "The shell is about to be terminated, though, this is > forbidden", etc., and hangs. Loading the same driver with DEVLOAD from > FDAUTO.BAT works fine. > > 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's > CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading > the same TSRs manually works fine. > > 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with > other options), FreeCOM prints "Out of memory" instead of the expected long > file names - but "/LFN" by itself works fine. > > I think this is still an improvement compared to the previous version (if > compiled with OW), but the Turbo C++ version does not have any of these > problems. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hi Matej, > 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and > DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel > prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then > right after that I see "Not enough memory" ... Are you sure that this does not happen with older FreeCOM? You often get weird memory problems around the time when DOS starts using the HMA and other drivers or the shell start using XMS and/or UMB, because this is the moment when it becomes important that they really work stable. > I think this is still an improvement compared to the previous version > (if compiled with OW), but the Turbo C++ version does not have any of > these problems. Please explain :-) Regards, Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
I found these bugs in the OW version so far: 1. When loading SRDXMS.SYS (with only SHELLHIGH=COMMANDW.COM and DEVICE=JEMMEX.EXE processed at that point), the driver loads, the kernel prints "Kernel: allocated 48 Diskbuffers = 25536 Bytes in HMA", then right after that I see "Not enough memory" (not sure what prints that), and FreeCOM prints "The shell is about to be terminated, though, this is forbidden", etc., and hangs. Loading the same driver with DEVLOAD from FDAUTO.BAT works fine. 2. Sometimes, after loading some TSRs from FDAUTO.BAT (e.g. Bret Johnson's CLOCK), FreeCOM hangs, though I can't reliably reproduce that and loading the same TSRs manually works fine. 3. With the DIRCMD environment variable set to "/OGN/LFN" (possibly with other options), FreeCOM prints "Out of memory" instead of the expected long file names - but "/LFN" by itself works fine. I think this is still an improvement compared to the previous version (if compiled with OW), but the Turbo C++ version does not have any of these problems. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre3 prerelease
Thanks Bart. Amazing OW build is more compact than TC one. Pretty fine! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Remitente:Bart Oldeman Destinatario: Technical discussion and questions for FreeDOS developers. Fecha:sábado, 3 de febrero de 2018, 11:44:21 Asunto: [Freedos-devel] FreeCOM 0.84-pre3 prerelease Archivos: --===-- Hi, as some of you know I spent some time fixing various bugs in FreeCOM. We've had the awkward situation of still having an old 2006 version in distributions but the newer versions had too many bugs (e.g. loadhigh, ren "myfile myfile.txt", strange dir output depending on the country setting). However the newer versions support LFNs much better. So for testing I uploaded a new prerelease on github: https://github.com/bartoldeman/freecom/releases/tag/com084pre3 There are three non-UPXed xms-swap command.com's in the binary zip, one compiled with Turbo C++ 1.01 (as the older version were), one cross-compiled with OW 1.9 and one cross-compiled with ia16-elf-gcc. Please test and let me know how stable they are in your testing. As a bonus for the XMS swap version the resident footprint has been reduced from 3008 bytes (old Turbo C version) to 2304 bytes (new OW version). Bart -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeCOM 0.84-pre3 prerelease
Hi, as some of you know I spent some time fixing various bugs in FreeCOM. We've had the awkward situation of still having an old 2006 version in distributions but the newer versions had too many bugs (e.g. loadhigh, ren "myfile myfile.txt", strange dir output depending on the country setting). However the newer versions support LFNs much better. So for testing I uploaded a new prerelease on github: https://github.com/bartoldeman/freecom/releases/tag/com084pre3 There are three non-UPXed xms-swap command.com's in the binary zip, one compiled with Turbo C++ 1.01 (as the older version were), one cross-compiled with OW 1.9 and one cross-compiled with ia16-elf-gcc. Please test and let me know how stable they are in your testing. As a bonus for the XMS swap version the resident footprint has been reduced from 3008 bytes (old Turbo C version) to 2304 bytes (new OW version). Bart -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel