Re: [Freedos-devel] building freedos
2009/3/24 Japheth : > I'm not a lawyer. But I used my brain and asked myself the following > questions: > > 1. What is Open Watcom, is it a part of Sybase? > 2. If OW is NOT a part of Sybase, is it a - juristic - person which probably > could have a - disclosed - contract with Sybase concerning the distribution of > the old "Watcom" source code? > > I answered both questions with No. My conclusion therefore is: I can do the > same what Open Watcom does, that is, modify the source and distribute it. So > IMO your conclusion is wrong. True. Also, clearly, the license satisfies OSI's conditions. http://www.opensource.org/docs/osd The reason why is that you must read clause 2.1 and 2.2 as *both* giving permission: they do not restrict each other. I.e.: Clause 2.2 allows you to do something with Covered Code (which is the thing that matters here) subject to clauses 2.1a,b,c, and 2.2b,c,d,e; Clause 2.1 allows you to do *more* for personal/internal use of Original Code (the pre OW1.0 source code release by Sybase, and Sybase copyrighted subset of the current OW code): for personal/internal use of Original Code you may ignore clauses 2.2b,c,d and e. The Sybase license is almost the same as an older version of the Apple Public Source License (APSL), so the reasons why it doesn't satisfies FSF's conditions are here: http://www.gnu.org/philosophy/historical-apsl.html Now, Apple released a new version http://www.gnu.org/philosophy/apsl.html which is accepted by the FSF and Fedora...(but not Debian: it considers it "almost free") A draft 2.0 license for OW was published over 5 years ago that makes it more clear and very similar to APSL 2.0... unfortunately it never got post draft. I guess Sybase lawyers had other priorities... http://www.openwatcom.org/ftp/devel/license-2.pdf Debian, by the way, has DOSEMU and FreeDOS in the "contrib" section because of the compiler license issue. It is not in "nonfree" because the source code of DOSEMU and FreeDOS themselves are free. IIRC, SciTech, the company that was but is no longer involved in opensourcing Watcom wanted a much more liberal license such as the 3-clause BSD license but Sybase decided otherwise. Bart (IANAL) -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Closed: FIXED
2009/6/18 dos386 > > I possibly know what the problem is (re-confirmed with FD 2038 and EDR > 2009-03-28) : > > 2. UIP seems to do a very strange thing: it brews a temp file (AH=$5A, > regrettably not > visible above, but there was ONE call to it per attempt), throws away > the handle (!!!), and re-creates the file with $3C [1] ... what is > supposed to happen ??? Then it deletes the original file and renames > the (still opened) temp file to original name [2] ... and leaves both > (!!!) files present in the directory and empty ... and additionally a > dead cluster chain :-( The problem in the end is that when you close a just created file, and it has not been written too, then the directory entry should *NOT* be updated (the entry was created though, at creation time, of course), so closing the handle from AH=$5A should not cause any disk activity. This is all influenced by bit 6 in the device information word (RBIL Table 01423), and FreeDOS was clearing that bit for just created or replaced files (in kernel 2038, it was setting the fnode F_DMOD field, which does the same thing). MSDOS doesn't clear that bit, so SVN rev 1453 corrects it and fixes the UIP bug. Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] kernel SVN build availability
2009/6/23 Tom Ehlert > one thing, though: there MUST be the possibility to keep the dates of > > the source files to the last change, not the last checkout. > > with all files having a date of 22.06.2008 the date is meaningless. Jeremy, did you try "svn export" to another directory before zipping up? Here that gets you the original modification dates. You can either "svn export" directly from sourceforge or do it straight from the working directory. Tom, note that the latest kernel source (with the correct dates) is also always automatically available here: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk.tar.gz Bart -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel Build
2010/2/8 Braden Mailloux : > I built the kernel with DOS compilers in an NT environment. Afterwards, > NTLDR disappeared. Related? It's better to use the NT-hosted compilers in %WATCOM%\BINNT. DPMI support in the Windows NT family isn't very good (and non-existent in 64-bit Windows). The example in build.bat with %WATCOM%\BINW in the PATH is geared towards building FreeDOS in real (Free)DOS. dos386 wrote: > I wonder whether FreeDOS can compile on itself at all ... sure I've done it many times. However, I still haven't been able to reproduce the data corruption bug you reported, and could not find any file start cluster 32->16bit truncation in the source code :( If there exists a batch file that could reproduce it (which includes formatting the hard disk partition, putting files on it, and information about the size), that would be most welcome -- from your info I'd assume that once the disk is full enough to go over 64k clusters some corruption should occur, but I did not see it happening. Bart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.1 (again)
On 4 May 2011 15:18, Bernd Blaauw wrote: > FREECOM (updated (in progress ?) or not (from 2003)) > > Still same one I guess, unless Jeremy, Pat or Blair succeeded in improving > things like porting to Openwatcom for example. I just finished porting FREECOM in SVN to OpenWatcom. It seems to work properly now including the XMS swapping, though it could use some more testing. I had to use some of the kernel build infrastructure to be able to still also build with Turbo C(++). Writing portable DOS makefiles causes all sorts of funny restrictions, esp. dealing with Turbo C 2.01 make: it cannot do command line redirection. That's also where some of the large changes were for that Eric saw on the freecom-cvs mailing list, the other being a further pruning of the included SUPPL files. Bart -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.1 (again)
On 5 May 2011 10:52, Rugxulo wrote: > On Wed, May 4, 2011 at 3:03 PM, Alain Mouette wrote: >> >> Em 04-05-2011 16:45, Bart Oldeman escreveu: >>> >>> I had to use some of the kernel build infrastructure to be able to >>> still also build with Turbo C(++). Writing portable DOS makefiles >>> causes all sorts of funny restrictions, esp. dealing with Turbo C 2.01 >>> make: it cannot do command line redirection. >> >> Why not use some other make, like gmake? so freedos only compiles with >> it and the mess is fixed (at least partialy)? >> >> This make problem has been a nightmare around here too ;-) > > IIRC, there was a real-mode GNU Make 3.71 or such a long time ago. I > remember I archived it (on my old P166), but I never bothered with it > much. So it may not be perfect, but it does exist! Perhaps found at > GNUish mirror sites. (Dmake also exists, but I doubt it's better. > Oops, forgot OpenWatcom has WmakeR [real mode] now too.) yes I know, I reviewed gnuish make (3.58 & 3.71) and dmake a long time ago. There were conventional memory and stability issues at the time. In the end it was easier to instruct people to just use the make utility that ships with the compiler. The redirection issue from Turbo C make could be avoided by using a special "echoto.bat" batch file that does "echo >>". FreeCOM could be built with dmake (http://www.freedos.org/software/?prog=dmake) but the relevant makefiles have not been maintained since Steffen Kaiser stopped with FreeCOM. I'm not sure why WmakeR is that relevant -- protected mode make works fine too (I know I know -- some people want in principle that you should be able to compile all of FreeDOS on an XT but this has never been policy; the cost issue was there in 1995 but these days Pentium 3's and under aren't even accepted at charities anymore). > BTW, Bart, were you ever cc'd in that email of mine a long time ago > re: FDISK's makefile problems? IIRC, it was regarding long cmdlines > > 126 bytes that I quoted from an old Turbo C++ 1.0 book. Okay, maybe > that's not totally relevant, but I can forward it if interested (or > look up similar). I realize that TC 2.01 is slightly different, maybe > more limited, but hey, it can't hurt for reference. Just sayin' I just looked up that email. This ( MYPROG.EXE: $(MYOBJS) tlink /c @&&! C0S $(MYOBJS) $* $* $(MYLIBS) EMU.LIB MATHS.LIB CS.LIB ! ) is the syntax that was used in FreeCOM and I changed to use echoto.bat, because it isn't supported by any other make (even TC2.01's make), like this: MYOBJS1 = ... MYOBJS2 = ... MYOBJS = $(MYOBJS1) $(MYOBJS2) myprog.lnk: if exist myprog.lnk del myprog.lnk echoto myprog.lnk C0S $(MYOBJS1) echoto myprog.lnk $(MYOBJS2) echoto myprog.lnk myprog echoto myprog.lnk myprog echoto myprog.lnk $(MYLIBS) EMU.LIB MATHS.LIB CS.LIB MYPROG.EXE: myprog.lnk $(MYOBJS) tlink /c @myprog.lnk the objects are split because the echoto command line is restricted to 128 bytes. Very ugly but doable. > P.S. Bart, thanks for your efforts over the years. I know that's not > much from me, but you're welcome. Bart -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Severe bug in kernel 2040
On 18 May 2011 11:04, Ladislav Lacina wrote: > I found severe incompatibility between new SVN kernel 2040 and LD.EXE in > version 2.9.1. > LD.EXE is part of DJGPP or Freepascal. > It is not able to create output file when linking. First symptom I faced was > that Freepascal 1.0.10 does not more compile any files (end with message > "error in linking") Hi, in fact the SVN kernel was fixed 10 days ago (I saw the bug somewhere else) but the binary at http://dosemu.org/bart/kernel.sys was not. I uploaded a new binary now. The problem was that shrink_file (calling DOS write int21/ah=40 with cx=0 bytes shrinks or extends a file) could now give errors (previously it always succeeded) but was giving an error for truncating a 0-byte file to 0 bytes (an obvious no-op). Bart -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Severe bug in kernel 2040
On 19 May 2011 06:50, Rugxulo wrote: > But honestly, this is a weird bug, surely LD itself (from GNU) didn't > explicitly do this, did it? (I mean, why would it?) Mustn't it be a > DJGPP libc bug? But 2.9.1 is old old old (latest is 2.21 !!) from May > 1998, apparently, which would've been DJGPP 2.01 or such (instead of > current 2.03p2 or beta 2.04). It might well be libc, which was changed to ignore truncate errors because of Win2k/XP problems with character devices: http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/posix/fcntl/open.c.diff?r1=1.9&r2=1.10 But the operation isn't so odd: a "touch"ed 0 byte file when opened by the c-library open(...,O_TRUNC|O_RDWR) (without O_CREAT) will get you this. Bart -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Severe bug in kernel 2040
Hi, I updated the source in SVN and the binary at http://dosemu.org/bart/kernel.sys with your bug (below) fixed. Thanks for the report. I made 4 adjustments: 1. If there is no FSINFO sector, don't use it. 2. Range check the FSINFO values to make sure they are usable (that fixes the bug -- the DPB value for an unknown first free cluster is 0 (cf. RBIL, INT21/AH=53), not 0x and that confused things). 3. Since the FSINFO first free cluster value is just a hint, when searching for a free cluster the kernel now scans the whole FAT, just starting at the hint but wrapping around in case there is a free cluster before. 4. When calculating free space, we obtain the correct first free cluster almost for free. That speeds up step 6 in your report, which now succeeds. I noted that the FreeDOS kernel uses the FSINFO next free cluster value to mean the absolute first free cluster, but RBIL just says "cluster at which to start search when writing, usually the last cluster allocated", which is a lot weaker! Change 3 above accommodates this. bug: > * minor "can't-save-after-FSINFO-invalidation-BUG" > 0. Get FreeDOS kernel 2040 (see shot) > 1. Get a FAT28 volume with some free space > 2. Set both values in FSINFO to $' > 3. Reboot > 4. DIR > -- observed effect: takes centuries to peek the free space > 5. DIR > -- observed effect: no longer > 6. try to brew a file or subdirectory > -- observed effect: doesn't work (no problem in EDR-DOS) <<<--- BUG HERE > 7. try to brew a file or subdirectory > -- observed effect: no longer Bart -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Compiling with gcc
Hi, I finally uploaded a draft (not to be merged yet -- the patch needs to be split in nicer chunks!): https://github.com/bartoldeman/fdkernel/commits/ia16-elf-gcc-draft patch can be seen here: https://github.com/bartoldeman/fdkernel/commit/f873f2052e83fedadfd10b04d79d07246da30bbd Rugxulo wrote: > So they only patched it this year? That makes more sense (since GCC > IA16's initial public release seems to have been in April). Yes TK Chia took that repository and worked on that. It's just source code on github now, all DIY compilation. > Very interesting. (But what is the problem with 80kb? Slightly less > free memory? Not exactly a deal-breaker!) Indeed, less free memory, somewhat bigger kernel.sys file for those who still deal with floppies. Though it's improving, already 2.5k smaller than last time I wrote. >> Alternatively said: ia16-elf-gcc and binutils does not support OMF, >> only ELF, and therefore NO segment relocations, as ELF is flat. > > You mean even ELF (with 8-bit extensions) isn't fully supporting all > features? Jenner did indicate plans to maybe add OMF eventually, but > that sounds like it would be onerous. Don't hold your breath. Yes, OMF is more work in binutils. But it can work a little more cleanly than before with ELF using a linker script and explicit segments ie. instead of "jmp far symbol", had to do "jmp DGROUP:symbol" etc. > FYI, NASM is still cross-compiled via DJGPP for DOS with official > binaries (e.g. 2.13.01). But I'm not sure it can build natively (well, > unless you "configure" elsewhere.) I think OpenWatcom support has been > dropped entirely since (I don't know) 2.10? (But I can build 2.09.10 > via OW in DOS with no obvious problems.) But latest release is close > to almost compiling with OW again (and I think Joe Forster's fork is > using it). So far I have only cross-compiled from Linux, so I've ignored all things DJGPP. It would be nice to be able to do the compilation natively on DOS eventually though it's not my priority. 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
[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
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
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
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
[Freedos-devel] FreeCOM 0.84-pre4 prerelease
Hi, thanks everybody for the feedback. I now updated the prerelease to pre4 with just a few changes: * stabilized the ia16-elf-gcc version further * fixed "Out of memory" with the Open Watcom version * fixed build with Windows CMD (Tom Ehlert) * spelling fixes and Swedish translation updates (Anders Jonsson) https://github.com/bartoldeman/freecom/releases/tag/com084pre4 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
Re: [Freedos-devel] FreeCOM 0.84-pre4 prerelease
Hi, On 26 February 2018 at 18:21, Rugxulo wrote: > There's another valid .BAT (P5.BAT) that says "Syntax error" and > hangs. I haven't looked into exactly why yet. > > So then I temporarily switched to the Watcom build, but when I type > "cls", it says this (and then prompts for date and time): File not > found. - '' I found out the cause of the bug and fixed the bug in svn. The issue was with batch files that do not end in CRLF but just terminate without EOL (my own ones all have EOL at EOF). So that's a workaround. I could not find P5.BAT in metados. Also I could not reproduce the "cls" issue. When I used the watcom version in metados (ie. replacing a:\system\command.com) before the bugfix it behaved the same way as the Turbo and GCC version, that is, hang, so there was no way I could even type cls. 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
Re: [Freedos-devel] Translations for FreeCOM 0.84-pre4
Hi, I'll have a look on that website and see which translations are more up to date, then replace/add them. 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
[Freedos-devel] FreeCOM 0.84-pre5 prerelease
Hi, thanks again everybody for the feedback. I now updated the prerelease to pre5 with a few changes and bug fixes, most importantly: * Update translations (Serbian/Slovene/Turkish/French) * fixed: FOR %i IN (*.*) do @ECHO %i does not work * fixed: The shell doesn't display any error if exec fails * fixed: hang for batchfiles that do not end with an EOL character * plugged memory leak in and around comResFile() * simpler ia16-elf-gcc port since that compiler is more capable now * debug build fixes, now uses medium instead of large memory model (the release build uses the small model as usual) https://github.com/FDOS/freecom/releases/tag/com084pre5 (I moved the git repository to the FDOS github organisation that Jeremy Davis set up) 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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
Hi Eric,
On Thu, 16 Aug 2018 at 04:24, Eric Auer wrote:
> Could you tell more about the comResFile
> memory leak? Does it fix an old, elusive
> bug which has been on the list repeatedly?
no, it's not an old bug, it's related to getEnv("COMSPEC") using
dynamic pointers (since pre3) and the resulting filename now leaking
into memory.
Before, getEnv used 3 static pointers, which caused memory
fragmentation but did not leak. The leak was more visible in the debug
build which is how I found it.
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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
Hi Tom, > can we please have a new version number please. > > instead of >FreeCOM 0.84-pre5 prerelease beta 1 > > FreeCOM 0.85 prerelease That does not make much sense to me since 0.84 has not yet been released yet. there is no beta1 (not sure where you read that, if it's there by accident I'll remove it :), just 0.84-pre5, once it's stable that becomes 0.84 and I can just drop the pre. But unfortunately it's not so I kept increasing the number after pre. Next will be pre6. 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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
This change seems to be the cause (which was motivated by the fact
that otherwise with large memory model regular malloc's would fail as
they bumped into the allocated memory block)
--- a/cmd/dir.c
+++ b/cmd/dir.c
@@ -1010,7 +1010,8 @@ static int dir_list(int pathlen
error_out_of_memory();
optO = 0;
} else {
- orderArray = MK_SEG_PTR(void, DOSalloc(0x1000,0));
+ /* use last-fit allocation to work well with large model */
+ orderArray = MK_SEG_PTR(void, DOSalloc(0x1000,2));
if(!orderArray) {
free(orderIndex);
error_out_of_dos_memory();
if I change it back to 0 it's ok. The large memory model is only used
for debugging though ... I am still puzzled as to why last-fit
allocation seems to cause memory corruption (with small model here!)
and first-fit does not.
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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
Upon further investigation a mere allocation of
orderArray = MK_SEG_PTR(void, DOSalloc(0x1000,2));
before the main dir code and deallocating it at the end without even
using orderArray for sorting already corrupts things.
I suspect that the memory block used for the message strings is
getting in the way and may be out of bounds some where.
On Mon, 20 Aug 2018 at 22:23, Bart Oldeman wrote:
>
> This change seems to be the cause (which was motivated by the fact
> that otherwise with large memory model regular malloc's would fail as
> they bumped into the allocated memory block)
> --- a/cmd/dir.c
> +++ b/cmd/dir.c
> @@ -1010,7 +1010,8 @@ static int dir_list(int pathlen
> error_out_of_memory();
> optO = 0;
> } else {
> - orderArray = MK_SEG_PTR(void, DOSalloc(0x1000,0));
> + /* use last-fit allocation to work well with large model */
> + orderArray = MK_SEG_PTR(void, DOSalloc(0x1000,2));
> if(!orderArray) {
> free(orderIndex);
> error_out_of_dos_memory();
>
> if I change it back to 0 it's ok. The large memory model is only used
> for debugging though ... I am still puzzled as to why last-fit
> allocation seems to cause memory corruption (with small model here!)
> and first-fit does not.
>
> 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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
Hi TK, > However, both the intr ( ) implementation in Open Watcom, and the intr ( > ) implementation in suppl/src/intr.asm used when compiling with > gcc-ia16, will _not_ try to load any flags --- including CF --- from > reg.x.flags, so int 0x21 basically gets called with CF in an undefined > state (and it happens to be set in commandg's case). And DOSBox's > implementation of the "get allocation strategy" call does not change CF. perhaps the best is to use suppl/src/intr.asm for both OW and GCC, and make it respect CF in flags. btw you should know that I have only ever compiled on a 32-bit Linux host using gcc-ia16 -- the code for the build helpers (fixstrs.exe,ptchsize.exe etc) may not be 64-bit safe yet: you may need to add -m32 to the gcc lines in mkfiles/gcc.mak to get the compilation working on a 64-bit host. 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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
Hello Tom,
On Sun, 26 Aug 2018 at 13:03, Tom Ehlert wrote:
> I think I found the cause for command crashing:
>
> the size to swap out, and back in, is only calculated once in
>XMSinit() {
>...
>mcb = MK_SEG_PTR (struct MCB, SEG2MCB (_psp));
>xms_block_size = SwapTransientSize = mcb->mcb_size;
>
>
> now if the size of command.com in memory ever changes,
> to little is saved/restored.
I think it is related somewhere to MCB corruption but still not sure where.
Somehow it happens after the strings are copied back in from XMS. I`ll
still have to dig deeper.
As for size... this is possible with OW if the heap overflows:
For GCC and TC the stack is above the heap so if the heap overflows it
corrupts the stack but the legally accessible part of DS (ie. near
memory space) cannot grow because the top of the stack is fixed.
For OW the heap is beyond the stack. If sbrk() needs to grow the heap
it can indeed do so dynamically.
If you fix the heap size to be bigger to start with in build.bat
(build.sh for Linux cross compilation) then it won't need growing.
I already played a bit with that but so far no big change.
Btw for me a broken OW-compiled command.com boots metados fast and
leaves only 3 directories in g:\ because something odd happens with
DIR and its sort buffer as soon as the special string buffer is used.
A correct one boots slower and leaves 6 directories in g:\. It's all a
question of fairly time consuming narrowing down where odd behaviour
happens first and why.
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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
Ok, I am getting a bit closer after pruning fdauto.bat as much as possible: this two-line fdauto.bat causes "String #" errors when typing dir in metados for the OW command.com: a:\system\shsurdrv /qq /d60M$SCRATCH,g set /e FINDDO=dir /od/s/a-d/b a:\stubs.zip looks like an issue with "set /e" so I will look there. 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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
Even simpler: a:\system\sleep 1 dir /od/b the first command is just to trigger one xms swap, and then after swapping in "dir /od/b" (both flags are necessary) causes trouble. 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
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
I fixed this issue now. There were issues with #pragma aux for OW and for GCC inline asm. The si parameter for XMScopy was not passed correctly for OW (likewise for DS for GCC), which meant that most XMScopy calls failed. However it would work by accident because the strings usually simply stayed where they were, even without swapping them back in, if the segment for the messages had not changed, and the messages were not overwritten. The changes are here: OW: https://github.com/FDOS/freecom/commit/5c8321f50fe4b3ead704c8c69ddc1b777e6a248d and GCC: https://github.com/FDOS/freecom/commit/7d389c650222c26845d830454dd56447d144c8cf 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
[Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi, thanks again everybody for the feedback. I now updated the prerelease to pre6 with mostly bug fixes and one build system change, most importantly: * Enable reporting of directory sizes up to 2TB (with Tom Ehlert) * Enable cross-compilation from 64-bit Windows using Open Watcom * Fix swapping of strings to XMS for GCC and OW versions (with TK Chia) * Fix carry flag handling on input to DOS memory allocation functions for GCC and OW (with TK Chia) * Fix compilation errors with LFN disabled * GCC inline assembly fixes (TK Chia) * shift: use correct context, Fixes SF Bug #155 (Wolfram Sang) * Fix buffer overflow with alias expansion, introduced in 0.84-pre3. https://github.com/FDOS/freecom/releases/tag/com084pre6 I hope this is finally stable enough for me to remove the pre6 and release this as 0.84. Happy testing! 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
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi Tom, > is there any reason why the source code version control system trashes > file modification dates? the underlying reason is to play well with "make" so that say if you check out a file as it was two years ago and then use "make", make will compile it because the timestamp of the file will be the current date which is newer than the timestamp of the object file that you still kept around. https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F For github those source code zipfiles and tarballs are automatically generated from a tag, I did not upload them myself. It is possible though somehow to convince it to use last-modification time == last time that file was really changed by using a hook. I can look into that. -- 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-pre6 prerelease
Hi Tom, > when I replace freecomW as compiled by Bart by a > watcom compiled by me, the bugs vanish. > compiled by wcc 1.9 > barts freecom has length 84756 > myfreecom has length 82758 (without UPX) > should this not be identical? yes they should be identical, as I also used wcc 1.9. I'll double check later today. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi Tom, the big one is built with xms-swap, yours without. I get 82758 also without xms-swap. So it looks like something in the swap code is still buggy then ... Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi Tom, interestingly picoc is still buggy after I disable XMSinit() and XMSexec() in the xms-swap build. This makes debugging a bit easier now that that code is eliminated. On Tue, 23 Oct 2018 at 19:12, Bart Oldeman wrote: > > Hi Tom, > > the big one is built with xms-swap, yours without. I get 82758 also > without xms-swap. > So it looks like something in the swap code is still buggy then ... > > Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi Tom, strtok's source can be browsed here: http://perforce.openwatcom.org:4000/@md=d&cd=//depot/openwatcom/bld/clib/string/c/&cdf=//depot/openwatcom/bld/clib/string/c/strtok.c&sr=33595&c=sgp@//depot/openwatcom/bld/clib/string/c/strtok.c Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi Tom, the issue is that OW strtok() detects characters in the set using a bitmask and uses an 8 char lookup table called _Bits (__Bits in the mapfile) which normally has this 01 02 04 08 10 20 40 80 (in hex) A printf confirms that this table is overwritten, so there is a buffer overflow somewhere. I'll dig further... Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi Tom, so in the end the issue is a stack overflow: filenames on the stack overflow into a const buffer used by strtok. I had raised it from 2K to 4K back in January but that is not enough. Since Blair Campbell's LFN work in 2006 cmd_rename() which calls fillFnam() together use at least 13 ~256-sized fixed sized filename buffers, which is already 3.3K right there. You can raise the stack for OW in shell/wlinker.bat to at least 6K, maybe 8K is better to be more on the safe side. Or alternatively redesign that code a bit to use less stack space. Or also just compile without -s to enable stack checking and see what that gives. I'll do some more tests tomorrow. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Python on freedos.
Hi Pär, no, DOS support was bitrotted and then removed for Python 3.5 (https://bugs.python.org/issue22591) in 2014. Newest full Python you can get is Python 2.4.2 at http://www.caddit.net/pythond/, but that's a long way before python 3. It works, I used it a long time ago. Indeed you'll have to look at micropython for DOS instead. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Tom, you are (in your words) 110% right. At the time I had fixed the stack offenders but got lost in debugging adapting your stack-checking patch to other compilers (it actually checks the heap too, if heap grows to stack). The OW version looked reasonably stable, the GCC version still ran into some issues if I remember correctly. Hopefully I can get around uploading a new prerelease sometime this weekend, and make it the real release if it works ok. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi TK, thanks for offering to help. I now pushed a GCC-portable version of Tom's stack check to freecom's git: https://github.com/FDOS/freecom However if you try to compile it you'll see once you run it that it says 0 stack left quite quickly. The reason is not the stack (there is plenty) but the heap which grows towards the stack. The default heap is very small though (6K), still it grows much further than OW's (with OW the stack is below the heap though but I debugged it a few times). You can easily make it bigger in build.sh, with 8K metados boots. I tried to limit heap grow a bit using a patch to nanomalloc https://gist.github.com/f45f2874b16afd8957d019db6182067e which basically takes any free block at the end into account when it needs to grow the heap via sbrk, so it does not leave a hole there. Anyway, even with that and 8K, "tests oberon16" in metados still fails. With OW command.com "tests oberon16" finishes (although it reports "BEF - bad command or file name" in the beginning), but if I run it twice the second one fails with invalid opcodes (ie. memory corruption). I'll debug this some more to see if older freecoms had this issue too. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre6 prerelease
Hi Tom, sbrk is a little deceiving here since it just administrates a high-water mark and does not allocate memory from DOS: old: https://github.com/tkchia/newlib-ia16/blob/e7c08882834a41d848698a19deae49089c2dab17/libgloss/ia16/dos-sbrk.c which only returned NULL if heap ptr went beyond 64K (the libc for ia16-elf-gcc started very bare bones in this respect!) new (just changed by TK Chia) https://github.com/tkchia/newlib-ia16/blob/newlib-2_4_0-ia16-tkchia/libgloss/ia16/dos-sbrk.c malloc returns NULL when the end of the heap is reached but this is not always checked properly in freecom, but at least it does not grow into the stack any more. One could easily swap heap and stack in ia16-elf-gcc though I think we would just see different memory corruption, stack can then go corrupt other data or even code. (that still leaves Turbo C which also grows heap to stack.. and of course protected mode OSes do it but with virtual memory protection they never get close to each other, and this is what can make small mode DOS debugging extra hard). Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeCOM 0.84-pre7 prerelease
Hi, better late than never and just within the 2010's here is finally another prerelease. There have been mostly bug fixes, most importantly the stack overflows that plagues the previous prereleases. I've added Tom's check to be notified if others pop up. Some fixes for LOADFIX and LOADHIGH are included as well. One can also now escape the characters > < | via ^> ^< and ^| e.g. in "echo", and the GCC-compiled version is a lot smaller (almost as small as the OW-compiled version), thanks to T.K. Chia's improvements with register calling) https://github.com/FDOS/freecom/releases/tag/com084pre7 I hope this is finally stable enough for me to remove the pre7 and release this as 0.84. Happy testing and 2020! Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre7 prerelease
Hi Louis, you should just be able to copy config.std to config.mak with zero modifications (which is what I do). You only need to modify it if you want to change compilation flags and debug settings. The same applies to config.h, which is mostly compiler-independent. The main thing with gcc-ia16 is that the build has only been tested "cross", under Linux (by myself) or Windows with MSYS2 (with *-mingw32-gcc and ia16-elf-gcc, by lpproj) with build.sh instead of build.bat, and build.bat does not support GCC (this I should add explicitly to docs\compile.txt). Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] stuck / forked freedos core component development!
Hi Jeremy, > At some point I may redo the kernel repository on GitHub, the current one was > initially from a released source and not git to svn conversation so is > missing history before that release. Archiving current one and doing the git > <-> svn sync with a new one looses the link to existing forks on GitHub, but > as it is, the history is missing. I'm open to suggestions. The kernel repository already has the history since I pushed that 2.5 years ago but in a separate branch.. it's possible to use "git replace" to link the two histories together. it's here: https://github.com/FDOS/kernel/commits/svn-trunk The master branch goes back to Oct 14, 2012 with commit c4311571 and that corresponds to d9225354 in the svn-trunk branch which ends at Feb 7, 2012 and goes back all the way to Jim's initial CVS commit on May 6, 2000. Also having "FDOS / kernel: forked from PerditionC/fdkernel" is confusing.. it should be the other way around. I'll try to figure out how later. > I don't usually respond, but I do read most of what goes on with FreeDOS. I don't respond much any more either, but yes the sourceforge repos aren't clear that development moved to github (all the freecom rc's I have posted were on github, and announced as such, so I don't understand why that was such a "secret"), which really happened around 2015 already. Although I was taking a complete break from freedos for a while back, I think I came back a little in 2017. If I can still change things on sourceforge I can make it more clear, otherwise I'll ask (give instructions to) the people who can as I moved another project from SF to github so know where to put it. Bart ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [announce] freedos kernel build 2033
The newest freedos kernel is up at sourceforge now, at the usual places -- http://sourceforge.net/project/showfiles.php?group_id=5109 you can construct the urls from previous announcements. The emphasis for this release was on fixing bugs. short list of changes: bugs fixed: - 1712 findfirst returns wrong filename[0] in TP 7 - 1722 "COPY X+Y Z" which makes drive overfull causes corruption - 1729 int21 func 3d (open handle) doesn't work for char device - 1730 int 0x21 func 0x44 (ioctl) has problem with char devices - 1737 external stdin stdout filter fails in BP7 IDE (grep2msg) - fix when DosUpChar() is called via CharMapSrvc with DS != SS - ctty now works without funny characters repairing onscreen. - sys corrects sectors/track, head and hidden sector values in the boot sector when appropriate - FAT32 kernels now ignore the high word of cluster numbers on FAT16 partitions (as they should) - Use a table so that FATs won't be too big for FAT32 partitions. - Improve FAT size calculations - fix problem with creating r/o files - fix int2f/ax=1216. Affects Artz Praxis Wiegand, a German program for medical doctors. - fixes for multisegmented device drivers, in particular DUSE - fix FCB problems with int21/ah=27,28 (RandomBlockIO) - fix boot sector problems with largish FAT12 partitions. new features: - sys now has a /L option to specify the kernel load segment - the SET command is now supported in config.sys. - allow 0 as a menu item in fullscreen menus - the kernel prints a message to run chkdsk if it ever has to encounters invalid cluster numbers in the FAT - added (basic) support for the following int2f functions: ax=1211h NORMALIZE ASCIZ FILENAME ax=1220h (get job file table entry). also affects APW. ax=4a33h CHECK MS-DOS VERSION 7; necessary for SpinRite (Steve Gibson) Enjoy, Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [announce] freedos kernel build 2033
The newest freedos kernel is up at sourceforge now, at the usual places -- http://sourceforge.net/project/showfiles.php?group_id=5109 you can construct the urls from previous announcements. The emphasis for this release was on fixing bugs. short list of changes: bugs fixed: - 1712 findfirst returns wrong filename[0] in TP 7 - 1722 "COPY X+Y Z" which makes drive overfull causes corruption - 1729 int21 func 3d (open handle) doesn't work for char device - 1730 int 0x21 func 0x44 (ioctl) has problem with char devices - 1737 external stdin stdout filter fails in BP7 IDE (grep2msg) - fix when DosUpChar() is called via CharMapSrvc with DS != SS - ctty now works without funny characters repairing onscreen. - sys corrects sectors/track, head and hidden sector values in the boot sector when appropriate - FAT32 kernels now ignore the high word of cluster numbers on FAT16 partitions (as they should) - Use a table so that FATs won't be too big for FAT32 partitions. - Improve FAT size calculations - fix problem with creating r/o files - fix int2f/ax=1216. Affects Artz Praxis Wiegand, a German program for medical doctors. - fixes for multisegmented device drivers, in particular DUSE - fix FCB problems with int21/ah=27,28 (RandomBlockIO) - fix boot sector problems with largish FAT12 partitions. new features: - sys now has a /L option to specify the kernel load segment - the SET command is now supported in config.sys. - allow 0 as a menu item in fullscreen menus - the kernel prints a message to run chkdsk if it ever has to encounters invalid cluster numbers in the FAT - added (basic) support for the following int2f functions: ax=1211h NORMALIZE ASCIZ FILENAME ax=1220h (get job file table entry). also affects APW. ax=4a33h CHECK MS-DOS VERSION 7; necessary for SpinRite (Steve Gibson) Enjoy, Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Totaly weird DOSemu behavior
On Thu, 29 Jan 2004, Imre Leber wrote: > When testing defrag in DOSemu, it seems that i am constantly getting a > middle mouse button press, (from the int33h handler) even if i don't press > on the mouse. That is why the menu is so shaky (I don't get the same > behavior in MSDOS). Does anybody have ever seen similar behavior? yes, happens here too. If you do emumouse 3 at the DOS prompt in dosemu to tell it that you want to emulate a 3 button mouse the menu is stable though. I'll have a look if I can see where the problem is (in DOSEMU or not...). Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Q: watcom
On Tue, 3 Feb 2004, Arkady V.Belousov wrote: > - with BCC defaults for options may be written in turboc.cfg. How to reduce > command line in Watcom? Where (in which .ihp file) this explained (if this > possible at all)? environment variables or @file cguide.ihp has this information, look for the WCC env variable. This help file also tells you how #pragma works and various other optimization effects. Look for instance at "Describing how functions use memory". > - with BC stack size may be defined (in source!) by next definition: > extern unsigned _Cdecl _stklen = ...; > How do this in Watcom? Which default stack size in Watcom (and where this > explained)? There is the option stack= for the linker. Note that memory is organized differently; IIRC in small model for Turbo C you have (for the data segment): data - BSS - heap - stack whereas for Watcom it's data - BSS - stack - heap so you cannot dynamically change the stack size. default is stack size = 4096 (see the map file) > - how to compile .COM files? With command line > wlink form dos com file attrib.obj > wlink gives some errors about "segment relocation", then "stack segment > ignored", then page fault. Without "com" in command line, wlink generates > .exe file. With "sys com" instead "form dos com" wlink says "undefined > system name". In your example there must be something in the object that causes a segment relocation. You'll have to strip it down to find out where; it shouldn't happen for "hello world". > - when I run wlink without LIB environment variable, it can't find > libraries. Bug (ignored libpath in wlink.lnk/wlsystem.lnk)? (Of course, > WATCOM variable is defined). If you just use "form dos" or "form dos com" then it cannot find the libraries. wlink sys com f hello.obj should work without a LIB environment variable though -- I see that WLINK looks for wlink.lnk in the PATH (explained in lguide.ihp) > - BCC generates 9148 bytes of ATTRIB.COM (7306 with redifinition for some > RTL functions), Watcom generates 10296 bytes of ATTRIB.EXE (with WPP > options -ms-ox). How I may reduce size of executables? -ox isn't the best for codesize. It does -obmiler -s; wpp does -obmilr -s. Anyway, -os -s or -oas -s or -oals -s will generally be smaller. Also watcom's printf is fairly large since it deals with 64-bit integers (long long) and wide characters. Have a look at the map file; perhaps you can replace a few functions by stubs. Replacing printf, malloc and free, and getenv (as is done in SYS; because Watcom follows MS here and made getenv case-insensitive a whole bunch of uppercase tables had to be linked in) makes quite a difference. getcmd() instead of main(argc, argv) can also reduce the size -- but it means you have to reorganize your option processing. the *o* libaries deal with overlays. The normal way to use the openwatcom people is through the news server (NNTP: news.openwatcom.org, groups openwatcom.users.c_cpp and openwatcom.contributors). Not sure if you can reach that, there may be mail-to-news gateways but I don't know. There's also a bugzilla just like for freedos. Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom
On Wed, 4 Feb 2004, Arkady V.Belousov wrote: > 3-æÅ×-2004 15:17 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to > [EMAIL PROTECTED]: > > LG> "_emit" can be replaced by "db", > > __emit__ (was) allow to point variable names (including local). Though, > I don't use this feature and now replace some __emit__ occurences by > explicit inline asm. BTW, some time ago I was use __emit__ because some > discussions (with tom) about inline asm was ended that "emit is better > because more predicatable". in general #pragma aux works best with OW's optimizer since you can tell it exactly which registers are clobbered; inline assembly using _asm was bolted on much later to Watcom for MS compatibility and it's very pessimistic (basically assumes almost all registers may be clobbered, even worse than Turbo C which seems to scan inline asm for "si" and "di" but isn't very clever about them either, moreover "int" or outside procedures could clobber si and di too...). > BTW, does anyone know where I may find good describe for WASM language? > .ihp are too short and most useful part is where listed unsupported keywords > (like CATSTR). Doesn't inspires (to replace TASM). :( there isn't any WASM guide, it just doesn't exist (apart from the docs you already saw). It supports a subset of MASM syntax given by those keywords, apart from that you're solely on your own... Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Q: watcom
On Wed, 4 Feb 2004, Arkady V.Belousov wrote: > BO> Anyway, -os -s or -oas -s or -oals -s will generally be smaller. > > Looks like best (default) should be -obhklrs and sometime with > -oami[+]-s? Anyway, ATTRIB.OBJ for -obhklrs-oami+-s (almost) identical to > result with -oxshki+-s. hmm, I never got any size improvements for b and r. Inlining certainly didn't improve. > BO> perhaps you can replace a few functions by stubs. > > May you offer some ready stubs? I had a quick look at attrib. Its biggest user of space is fopen(). fopen() calls fseek() if "append" is set, so you can stub out fseek() as a no-op. fopen() also calls open(), and open() is quite a big user too; it maintains a dynamic array of file handle states (text/binary and so on); that's where the realloc() comes from. The default array is large enough for attrib though so you can stub realloc() too. Replacements for malloc() and free() will help; don't forget to define _nmalloc as a malloc caller. You'll get significant space savings if you replace fopen()/fgetc()/... by open()/read()/... and even more if you reimplement open() in terms of _dos_open() (likewise for read) and handle CR/LF yourself. try to use "wlink symtrace realloc_" and so on to see in the mapfile where it is called from. > PS: Is there option, which equal to "#pragma on (reuse_duplicate_strings)"? i don't know. If it exists it would be explained in cguide.ihp Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Q: watcom
On Wed, 4 Feb 2004, Steffen Kaiser wrote: > On Wed, 4 Feb 2004, Bart Oldeman wrote: > > > Replacements for malloc() and free() will help; don't forget to define > > _nmalloc as a malloc caller. > > Can you hook into Watcom's heap management? E.g. trace malloc() calls, > redo malloc(), if it failed (after some stuff has been deallocated)? I don't know. > Can I have implemented my heap without patching the clib? Yes. See talloc.c in the kernel source (sys directory) or choice. It implements a simple heap on top of __brk() and sbrk(). Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS ODIN 0.6
On Mon, 9 Feb 2004, Gregory Pietsch wrote: > I just checked the source for edlin from the Odin 0.6 package, and it's > missing various files such as the configure script. Please put these > files back into the distribution, as they are referenced in the README > and INSTALL files that comes with the edlin 2.1 distro. IIRC it was removed from the source that is distributed because: 1. it takes up > 160 kb -- autoconf related stuff takes up more than everything else taken together. 2. it's not necessary to reproduce the distributed edlin binary and is useless for 16bit DOS (and so it doesn't break with the GPL) It's reasonable for you to like people to redistribute the whole thing but it's reasonable for distributors to leave out unnecessary files. A similar situation occurs with freecom: to distribute its full source you also have to distribute the suppl source whereas only a small part of it is used in freecom, so it makes sense to strip down the suppl source if you need to make your source distribution smaller. IMHO a configure script for edlin is overhead even for gcc on Linux/UNIX, since it just uses standard ANSI/ISO C90. Maybe a compromise is possible? Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS ODIN 0.6
On Mon, 9 Feb 2004, Gregory Pietsch wrote: > Well, if you don't want to put the configure script in there, at least > leave everything else in there so that the configure script can be > reproduced with standard tools such as autoconf! well configure.in is at least small :) Anyway it's Bernd's decision. > What if I decided to > leave out config-h.bc and Makefile.bc as they are superfluous? depends if they were used for compilation or not. The guy distributing the binary must distribute the corresponding source code. It these files were used to produce the distributed edlin.exe then they must be redistributed. Otherwise at least the GPL doesn't require it. Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Tue, 10 Feb 2004, David Turner wrote: > I heard that you were considering a proprietary executable compression > scheme for FreeDOS. I'm just writing to let you know the licensing and > freedom implications of this. Now that you're here anyway ;) I have some questions too: first of all many FreeDOS binaries link some non-free code in the form of various compiler RTL library code. But as far as I understand this is allowed under the special GPL exception " However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." At one point the question was raised if that applies to the freedos *kernel* too. Since it does not (generally) run *on* an operating system because it is one itself. When I queried Pat Villani (original kernel author) he said that it was still fine as long as the to be included library code is automatically linked in by the compiler rather than code that was explicitly called (32 bit multiplication/div routines, a lot like gcc's libgcc). In any case for the kernel we have our own routines now. But still, because freedos binaries cannot be built with free compilers, for instance the "dosemu-freedos" package is forced into Debian's contrib section and "dosemu" is forced there too. GCC is out of the question, it really isn't designed to generate code for the 8086 (in particular "far" pointers; small model code would be possible but we really need those far pointers for many technical/compatibility reasons). One free compiler I have hope for though is OpenWatcom C; however its license is whilst OSI-approved not quite "free", just like the APSL was. The OW license is due to be updated however, and I asked about a while ago: [gnu.org #137546] AutoReply concerning licensing question: Enquiry about the Sybase Open Watcom Public License. my question was: " For a long time I have been looking for a free compiler for the FreeDOS project, as listed at http://www.gnu.org/directory/devel/prog/Other_programming_languages/freedos.html GCC is problematic since it cannot produce 16-bit x86 code, and it is very difficult to modify it to do so especially to get it to handle "near" and "far" pointers. So far we had to depend on proprietary compilers which was not very attractive, even more so now that these compilers have been abandoned by their manufacturers almost 10 years ago and it is impossible to fix bugs. One potentially free alternative that appeared on the horizon was Open Watcom; unfortunately its license is not GPL compatible. It is very similar to the APSL, which, at least in its 2.0 revision qualifies as free software. What I would like to ask you is if the proposed Sybase Open Watcom Public License 2.0 qualifies as free software as well, even with the differences that exist with respect to the APSL. It follows below, as converted from the PDF version that exists at http://www.openwatcom.org/ftp/license-2.pdf http://www.openwatcom.org/ftp/license-2-redline.pdf (this highlights the differences with the OW license 1.0, which is similar to the APSL 1.2 and hence not free software). If it is not free software I will try to ask the lawyers at Sybase to make the necessary changes. " Is any reply still possible? Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Tue, 10 Feb 2004, tom ehlert wrote: > DT> I heard that you were considering a proprietary executable compression > DT> scheme for FreeDOS. > could you explain 'proprietary' ? > > is everything non-GPL 'proprietary' ? proprietary is everything that is (in the eyes of the FSF) not Free Software. Definitely not everything non-GPL, but "Proprietary software is software that is not free or semi-free. Its use, redistribution or modification is prohibited, or requires you to ask for permission, or is restricted so much that you effectively can't do it freely." [http://www.fsf.org/philosophy/categories.html#TOCProprietarySoftware] any closed-source software is proprietary by this definition, since you are generally not allowed to modify it. Confusing? Well it's the FSF terminology and impossible to understand them without understanding the language. > the compressor is available to everyone, but simply does not allow > free distribution of compressed executables, if used comercially. it does not allow you to modify the stub. That's the main point. > could you explain the difference between a compiler and compressor ? > both take file X as input and produce Y as output. the compressor is not the problem. It is the stub. > GPL is a SOURCE license, not an EXECUTABLE one. > so I MAY COMPILE* some GPL code with the non-free MSVC compiler and > linker, but MAY NOT use option /EXEPACK ? here you are hitting the nail in that it is practically spoken a legal issue. /EXEPACK can be argued to be normally distributed with the compiler and is therefore part of the "special exception". Using APACK instead of EXEPACK is like using a third party RTL instead of the one shipped with the compiler. A FreeDOS binary GPLedprogram that is packed with APACK will consist of three sections: a) portions directly derived from our source (GPLed) b) RTL sections (part of compiler, covered by exception in GPL) c) APACK stub. Conflicts The practical question for you, if you want to release some source code and wish to choose a license is to answer the following: 1. Do I want to prevent others to derive closed-source applications from my source code? If Yes: a. do i want to prevent linkage with closed or non-GPL compatible libraries/stubs that are not part of the compiler? If Yes: GPL is a good choice If No: LGPL is a good choice If No: choose a simple license such as BSD or MIT/X11 they are all listed here: http://www.opensource.org/licenses/ IANAL Bart --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Wed, 11 Feb 2004, Luchezar Georgiev wrote: > There is a very good and easy interactive license selector at > http://pgl.yoyo.org/lqr/ but I'd still prefer if we compose one of our > own. More opinions, please! The FreeDOS kernel is released under the GPL and will remain so. Getting the agreement of all copyright holders (Pat Villani, John Price, ror4, James Tabor, Tom, Lucho, Martin, many others) to change it is an impossible task. It all rolls down to someone who wants to squeeze one more K out of the kernel.sys binary. So what, if the packer happens to be incompatible then it just is. As I see it, Pat contributed the kernel to the FreeDOS community (not to be underestimated, as I doubt this project would be anywhere without it); the license that he saw fit to do that was the GPL. With the GPL come certain freedoms at a cost of certain restrictions. If some restriction means not being able to compress it 1K further from 43K to 42K (and redistribute the result) then SO BE IT. Write your own exepacker if you don't like it! Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Thu, 12 Feb 2004, Luchezar Georgiev wrote: > On Thu, 12 Feb 2004 09:10:33 +0100, Roberto Mariottini wrote: > > > I understand you Lucho, but Bart is right: if it's not possible, then just it > > isn't. > > So, we are (OK, I am) in the trap of our own license! The GPL, instead > of giving us freedom, takes it away from *us*, the *developers*! Isn't > that absurd?! :-( no it's not absurd, to the contrary, it's the whole point of the GPL! Otherwise a BSD or MIT/X11 style license should be used. There are lots of things the developers cannot do, for instance distributing a closed-source program that derives from the FreeDOS kernel is not allowed either. But please note that the GPL only affects distribution, not usage. This is also why I think restricting military usage is pointless: the really bad guys will ignore such usage restrictions anyway. > Besides, nobody has yet written a *real*, convincing argument *why* we > have a "combining" and not "aggregation" between the different parts of > a compressed executable. This doesn't matter for the GPL. Aggregation only applies to having differently licensed seperate programs on one CD or in one zipfile, for instance. The only exception that may possibly apply is the "compiler" exception but I highly doubt that because a) an FSF spoke person did not mention it. b) the UPX authors clearly don't think so either. They clearly make an exception in the UPX license for non-GPLed binaries. Because otherwise, because of the GPL-ness for the stub the whole binary would need to be covered by the GPL! p.s. i'm deliberately ignoring upx-ucl vs. upx-nrv here -- it's besides the point since the stub they insert is the same. > So I'm not convinced yet that using aPack would > be illegal EVEN THOUGH I register my own copy No. *Using* apack is not restricted at all. You may apack all your FreeDOS executables. It's the *distribution* that is (likely) restricted by the GPL. You may even (subject to APACKs license) distribute: * kernel.exe * exeflat.exe * apack.exe then allow the user to apack and then exeflat the kernel. Now aggregation applies. Sounds ridiculous? Maybe. But you have to realize that the FSF has an agenda too, which likes to minimize the use of closed source software. Which such a technique it becomes crystal clear to the user that a non-free packer is involved. And, moreover, you give the user extra freedom by being able to use *any* packer, including upx, pklite and what have you. What speaks in favour of Steffen who just refuses to distribute pre-packed command.com's (neither do I pack command.com in the kernel binary zip by the way). Bart *PS. I really object to comments about Microsoft being "MASTERS" and lawyers being "monsters". I think this is highly inappropriate and does not contribute to the discussion at all. Many lawyers (some being pro-bono), after all, have helped people who were accused for crimes they were not involved in. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Thu, 12 Feb 2004, Aitor Santamaría Merino wrote: > By the way, I assume from this all that there's no GPL-ed packer. So I > suppose that according to the FSF agenda this means that, as there is no > GPL-ed packer, then I have to give up the ussage of packers, better than > using a closed source one. there is a completely GPLed packer, called upx-ucl (the one that you get when you compile UPX and UCL from source). It packs slightly weaker than the precompiled upx (upx-nrv). In Tom's comparison, for FreeCOM (~93000 bytes uncompressed) upx-ucl ~ 67500 bytes upx-nrv ~ 66000 bytes apack ~ 63800 bytes > Of course, one can't apply this to kernel, as Bart pointed out, but yet > for whoever wants to use this for his/her utilities. All that needed is a special exception clause to the GPL to clarify (with agreement of all copyright holders). However that makes the utility GPL-incompatible so it is no longer possible to copy/paste from other GPLed sources without permission from the copyright holder. Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Thu, 12 Feb 2004, Luchezar Georgiev wrote: > On Thu, 12 Feb 2004 15:14:40 + (GMT), Bart Oldeman wrote: > > > there is a completely GPLed packer, called upx-ucl (the one that you get > > when you compile UPX and UCL from source). It packs slightly weaker than > > the precompiled upx (upx-nrv). > > > > In Tom's comparison, for FreeCOM (~93000 bytes uncompressed) > > upx-ucl ~ 67500 bytes > > upx-nrv ~ 66000 bytes > > apack ~ 63800 bytes > > But you already wrote that since the STUB is the same, UPX-NRV *can* be used too - > and you do it. aitor specifically wondered about a GPLed *packer*. A bit like building the kernel using 100% Open Source tools -- then you'd only be able to use Open Watcom + NASM + upx-ucl. And, if you're smart enough, improve the compression ratio of ucl as well :) As to stub being aggregation vs. combining, please have a look at http://www.gnu.org/licenses/gpl-faq.html#TOCMereAggregation Now suppose you'd distribute the stub seperately from the rest of kernel.sys. Then kernel.sys on its own would be useless. So it is not independent of the stub -- in a way comparable to Windows programs that use DLLs. Also you'd distribute a closed stub + a GPLed kernel.sys that *depends* on it. Which sort of defeats the purpose of FreeDOS! You're on very shaky legal ground here... and hence I cannot say much more; and IMHO it's better to avoid such issues (try to save those K's somewhere else). Anyway, as you say there may be a solution, so I'll stay tuned. As to *why* Pat released the FreeDOS kernel under the GPL. I really don't know. He just did, as far as I'm concerned. According to a FD FAQ: DOS-C is open and will remain open. The source code is available to all under GNU GPL and I will continue to make it available in the future. Please do not make changes and fail to publish the source. This violates the purpose of DOS-C. DOS-C is not part of the FSF software collection, but I do use their GPL to protect my copyright and your right to redistribution. Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Fri, 13 Feb 2004, tom ehlert wrote: > as the EMM*.zip archives are selfcontradicting (because they claim to > be GPL, but aren't) they might crash any GPL-aware OS internal logic. > please remove them from all open source OS disks before you see a > kernel panic() ;) > Exactly my thinking. > but this would change licensing blablabla... Perhaps rather than blablabla about licensing I (or someone else) should (instead of writing emails) spend some time trying to get UPX to co-operate with himem.exe and emm386.exe. Programming after all is much clearer than all this license nonsense. I'll give it a go in a couple of weeks and will stop emailing for now. Honest. Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Executable compression
On Thu, 12 Feb 2004, Kenneth J. Davis wrote: > The 'major components' do not have to be provided _with_ the > OS, they must be _of_ the OS. Thus one can use any compiler, > linker, or whatever is deemed a major component of the OS. true. > So the even funnier part is about statically linked runtimes; > most people simply choose to ignore their existance otherwise > you have a serious problem -- no GPL'd [again assuming the > stock GPL license without such an exception] program can > legally be released if built with a compiler's (C/Pascal/VB/...) > normally included libraries including startup code unless > one has the right to pass the source of these libraries on > to others in terms compatible with the GPL. not true. I think the problem with the DLL you wanted to distribute is that the DLL itself was deemed a "major component". If the above is true then the GNUish project could never have existed, yet all programs in there are copyright FSF. This issue came up in '93 when somebody wanted to release a version of GNU Emacs for MS-Windows and MSDOS. DJGPP could not be used at the time since it was not yet compatible with Windows (3.x). Please refer to: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=C5E4yp.9C2%40srgenprp.sr.hp.com and the surrounding discussion. I don't see much difference between a DOS extender stub and a decompressor stub. Both wrap around "main()" and do something before calling it. In both cases the program (source code, not the specific binary) itself does not depend on the stub. Except that the dos extender came with the compiler but the decompressor stub not. How is this different from a .rar file? Very much so. The GPL does not care about what the stub exactly does. The fact that matters is that it is a) linked in and b) impossible to run the executable without the stub (dependency!) With a .rar file somebody can repack it as .zip and the .exe will still be the same. With APACK it is impossible to remove the stub. All in all, a *very hairy* subject. Best avoided by just not using an exepacker or staying with a GPL exepacker. If UPX can't compress himem.exe or emm386.exe then it can be changed to do so! Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] re: Executable compression
On Fri, 13 Feb 2004, Eric Auer wrote: > So UPX does not work at all for the "driver EXE" file format. Right, but UPX is GPLed so we can change it so it will work for the "driver EXE" format! Do you expect us to read all your long emails when you can't even read my short one? have a nice fortnight, Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Q: Watcom & debugging
On Tue, 24 Feb 2004 [EMAIL PROTECTED] wrote: > b) How can I debug those programs from within WinNT? Both the tools in > BINNT and BINW complain about invalid debugging information. I pass the > "-d3" option to WCC.EXE and WLINK.EXE gets "DEBUG WATCOM ALL". The > executable has lots of stuff appended, looking like debug infos. not sure here. You might try to narrow down though: first try: wcl -d1 hello.c wd hello.exe then: wcl -d2 hello.c wd hello.exe Also you might want to use "remote" debugging -- it's not really remote but it works the same way in that you regard the winnt dos box as a virtual machine: in a winnt dos box you type: vdmserv (hello.exe needs to be in the current directory) and you start binnt\wdw or binnt\wd using wdw /tr=vdm hello.exe (using start->run or another cmd.exe) wdw will now ask vdmserv to run/trace hello.exe. Bart --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
On Tue, 9 Mar 2004, Michael Devore wrote: > What we need people to do is try EMM386 with any DOS extended program > they may have available and see how well it works, or not, with > interactive feedback either way. NOEMS and NOVCPI may be tried for the > venturesome. Looks very promising! -- it looks like the programs work. But I see one problem now with both dos4gw 1.97 and causeway. fd kernel 2033, freecom 0.82pl3 config.sys: dos=umb,high lastdrive=z device=himem64.exe device=emm38664.exe shellhigh=command.com /e:2048 /p nothing loaded in autoexec.bat running *any* dos4gw or causeway program I tested I got a "dos mem corrupt message". simplest case: d:\watcom\binw>cwstub Causeway error 11: DOS reported an error or corrupt file found. dos mem corrupt, first_mcb=02c2 prev cf42:|4d 00 00 3c 10 06 (crap) notMZdf7f:|00 00 00 00 00 00 (all zeros here) no idea why -- perhaps there was an MCB here (possibly freecom as it puts various things at the top of the UMBs) and it was wiped out by something ... I'll try to narrow down and have a look later. The MCB chain corrupted message doesn't occur when using umbpci instead of emm386. And will also have a look at DJGPP programs later (using cwsdpmi). Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
Hi Erwin, > When I add /verbose I see >'EPROM at c800:, size 0 KB' > endlessly scrolling by ... try booting without emm386 and then: c:\>debug -dc800:0 2 -q If it says 55 AA 00 then something is very weird. I have 55 AA 40 at c000: which means: here's an "EPROM" (video bios) of 0x40*512 = 32K. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
Hi Erwin, > > > When I add /verbose I see > > >'EPROM at c800:, size 0 KB' > > > endlessly scrolling by ... > > > > try booting without emm386 and then: > > c:\>debug > > -dc800:0 2 > > If it says 55 AA 00 then something is very weird. > > It says 55 AA 01 > Is that "avarage" weird ? > So I would have 0x01*512 = 512byte video Bios > Wouldn't that be a little low (understatement). yes, indeed. The code is in emm386c.c, easy to see where: it divides 1/2 which becomes 0. This code could be changed to check every 512 bytes for a ROM instead of every 2k, and to avoid this division. The value for a 64k bios should be 0x80. Not sure about 128k (that's a little high) but what is the real size of your BIOS? Please check: c:\>debug -dc820:0 2 (i.e. 512 bytes later) Perhaps your BIOS is split. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] beta9, rc4.
Hi, I was wondering why we just have release candidates all the time now. Is the current official FreeDOS still beta8 then? It looks to me that a better naming would have been beta9rc1: beta9, ... and then instead of beta9rc4 beta12. There was a bit of confusion on my side when I understood that beta9rc3 would be equal to beta9 in September -- so I put up a dosemu-freedos-b9-bin.tgz for use with DOSEMU. Now some people are confused since the new tarball is called dosemu-freedos-b9r4-bin.tgz. Just see it as "beta9, revision 4" and then I can explain it again however :) Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
On Tue, 9 Mar 2004, Michael Devore wrote: > I'm a bit confused on the programs working part of your message. Does > EMM386 work for you under some circumstances with the extenders or does > it always fail under all circumstances? EMM386 works. All DPMI programs seem to work. I can enter and exit DJGPP compiled programs as often as I like without a crash. If I start a DOS/4GW or Causeway program it will run just fine (I can shoot as many monsters as I like in DOOM) but only once I exit the program I get the MCB chain corrupted message -- so for every run of DOOM or WCC or ... I have to reboot the computer. CWSTUB.EXE (without any parameters given) is just the simplest program for which this behaviour occurs. > If you exclude (X= > parameter in EMM386) the problematic ranges for any PROMs -- which it > looks like needs work in the original EMM386 code based on other > messages -- does it help any? I think the ranges are correct but will double check. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM386 with VCPI for testing
> > little high) but what is the real size of your BIOS? > > 256k that's very big -- it's probably not all visible then within DOS or everything between C000 and would be occupied with no rooms for UMBs. I should have said "VGA BIOS". > > Please check: > > c:\>debug > > -dc820:0 2 > > It reads FF FF FF ok. that'll be the unmapped space then. It looks like Lucho is right and you have a tiny 512 byte sized signature "EPROM" at c800:. That'll be easy to fix. If you can compile emm386 yourself you should change romsize = pmem[2] / 2; by romsize = (pmem[2] + 1) / 2; in EMM386C.C. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: 2. Contact for Bugzilla / 1755
On Thu, 11 Mar 2004, Jim Hall wrote: > Since you seem to have problems accessing Bugzilla with your NS4 > browser, I've modified the design banner & footer for Bugzilla to > eliminate the sidebar. > > This should work for you now. > > CC'ing the freedos-devel list because this is a global change to > Bugzilla, and I thought everyone might like to know. speaking about bugzilla, do you know more about the (at least for me except for the weekly nags) broken automatic email notifications? I did the test you asked for a couple months ago but you never came back to it. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New revision EMM386 with VCPI
On Fri, 12 Mar 2004, Michael Devore wrote: > If you would, please put this version of EMM386 through suitable tests, > particularly with protected mode/DOS extender stuff, and let me know the > results. Still have the same (exit) problem as last time. Also something weird is going on with NOEMS now: device=emm38664.exe noems /verbose NOEMS ... EPROM at c000:, size 32 KB (the video bios) XMS largest block 0x2fbc0(195520), XMS total mem 0x2fbc0(195520) (there's 192 Megs of RAM, makes sense) allocated 400kb from XMS MONITOR_ADDR 11 EMM_MEMORY_END 174000 TOTAL_MEMORY c00 total(available) EMS 6(5) pages = 96(80) kByte allocating 10 pages = 160KByte for UMB's allocating 160KByte for UMB's:EMM failed: func 43, out 8700 000a So for some strange reason emm386 thinks there are only 6(5) pages available and can't provide 10 UMB pages! Smells like an overflow somewhere down the line. Without NOEMS I get this EPROM at c000:, size 32 KB (the video bios) using PAGEFRAME e000: choosen FRAME address e000 XMS largest block 0x2fbc0(195520), XMS total mem 0x2fbc0(195520) allocated 33104kb from XMS MONITOR_ADDR 11 EMM_MEMORY_END 2164000 TOTAL_MEMORY c00 total(available) EMS 2048(2047) pages = 32768(32752) kByte allocating 6 pages = 96KByte for UMB's Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EMM38664.EXE compatibility
On Sun, 14 Mar 2004, Michael Devore wrote: > Looks like they are using another illegal instruction in V86, based on > the 0F 20 prefix, which I'll have to emulate in EMM386. In dosemu src/emu-i386/cpu.c we have to emulate a whole bunch. Including reads and writes of cr*, tr* and dr*, but also rdtsc and ignore clts (0f 06). Not all of them may be necessary for a VCPI provider though... http://cvs.sourceforge.net/viewcvs.py/dosemu/dosemu/src/emu-i386/cpu.c?rev=1.4 Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UMB at F0000-F6FFF
On Tue, 16 Mar 2004, Michal H. Tyc wrote: > But I have also heard quite long time ago that on many machines you > can reuse whole 32K at F-F7FFF. I believe. I just never succeeded. If I remember well around '95 I could do that on my 386SX and there was an UMBPCI-style shareware program called "The Last Byte" that could take advantage of that. The later Pentium+ (AMD K5/K6-2) BIOSes I bought couldn't do it anymore as far as I could see. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mKEYB 0.40
On Wed, 17 Mar 2004, Luchezar Georgiev wrote: > On Wed, 17 Mar 2004 10:54:16 +0100, tom ehlert wrote: > > > MKEYB 0.40 released > > website http://www.drivesnapshot.de/freedos/mkeyb.htm > > download http://www.drivesnapshot.de/freedos/mkeyb.zip > > > > changes: > > now uses APACK for 200 byte smaller executable > > licensing changed to allow distribution of APACK'ed executables > > Great! But when I downloaded it, it turned out to be... the old version > (0.39)! :-( I wonder why you'd want to save 200 bytes anyway, when the disk space used is exactly the same (8002 -> 7802, both 16 sectors)? Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
On Tue, 16 Mar 2004, Michael Devore wrote: > Latest test version of EMM386 is at > ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and > EMMSRC.ZIP, as executable and source. > > These version corrects a problem with memory corruption in UMB's using > VCPI, particularly notable with MCB panic errors. Non-DOS upper memory > management is improved. This version should be compatible with a > greater range of DOS-extended software. yes, indeed. The MCB problems have disappeared now. Also with NOEMS I now get UMBs. So that's quite an improvement. Duke Nukem 3D reboots the machine as soon as it enters graphics mode. Its setup program (which also uses dos4gw 1.97) works correctly though. DOOM on the other hand works. Will try to run with Causeway and DOS32A later. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
On Wed, 17 Mar 2004, Michael Devore wrote: > I suppose I could break up the ZIP to floppy sized units, but I'm not > real thrilled about trying it. I'd very much rather get the CD problem > fixed. don't you have an old ISA network card you can put in the DOS machine? Then you could copy via a small network. I have an ssh server running on a Linux box and then transfer files locally using sshdos (sftp); encrypted might be overkill but it's easy and plenty fast with the cross-over ethernet cable. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
On Wed, 17 Mar 2004, Michael Devore wrote: > > > >Duke Nukem 3D reboots the machine as soon as it enters graphics mode. Its > >setup program (which also uses dos4gw 1.97) works correctly though. DOOM > >on the other hand works. Will try to run with Causeway and DOS32A later. > > I downloaded Duke Nukem 3D, but turns out it's larger than a floppy, > which is the only way I can transfer to the DOS machine. More info: Duke works fine in the standard 320x200 VGA mode but reboots when I try an LFB (Linear Frame Buffer) mode (800x600x256 in this case). So the problem is most likely in the LFB memory mapping. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mKEYB 0.40
On Thu, 18 Mar 2004, tom ehlert wrote: > >> Neither are most compilers in use for FreeDOS (with the exception of > >> watcom). > > LG> ...and the Borland Museum compilers. > > AFAIR, the Borland museum compilers have a license similar to > 'free for personal use. if you want to distribute compiled programs, >you have to buy a license' > > Unfortunately, I didn't buy a license - so mkeyb.exe is still illegal. > same for emm386, himem, more, if they were compiled by me. > > AFAIK, Eric doesn't have a license either; so this applies to his > MODE, also. > > Don't know if Bart has a TC/BC license; else all old kernels (compiled > with TC), are illegal, too. > > "personal use" applies to the compiler itself -- ie. you are not allowed to commercially redistribute that compiler. That's why it's not allowed to be on ibiblio for instance. Compiled programs are a different story. This was clarified by David Intersimone -- I was also confused about this. There are at least two places where he has said this: http://groups.google.com/groups?selm=3CCF4B75.D4B81422%40borland.com and in the forum http://threads.borland.com/threads/threads.exe/view?commentid=24952&view=short >From my POV the main issue with these museum compilers is that they are just that. We can't rely on them forever, bugs can be fixed in OpenWatcom, the optimizer can be improved and so on, whereas all Borland 16bit compilers are dead. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mKEYB 0.40
On Thu, 18 Mar 2004, tom ehlert wrote: > JH> What about Pat Villani, who wrote prf.c and portab.h? > this prf.c was written by the author of mkeyb, NOT pat villani. yes, prf.c was completely recoded in the early days I started maintaining the kernel. It's had some more updates from me in the kernel source (using stdarg.h etc) but these are not in mkeyb anyway. Who can sue Tom for changing the license? The copyright holders. Will they sue Tom? They'll have a tough time in court (because the contributions are minor and close to fair use) and need to spend lots of money. Why should I sue Tom? He seems to be a nice guy... I just chose to avoid the grey area by not using it. Distribute uncompressed executables, let the end user decide which exepacker is best for him. It's what Steffen does with freecom and I do with freecoma and sys in the kernel zip. Or use UPX (UPX-UCL if you're really paranoid -- I'm getting really tired of the NRV ranting, remember that NDAs are really nothing special, it just matters *what* they state, I even had to sign one for a pretty basic summer job 10 years ago, so I'll probably just use UPX-UCL for the next kernel version to avoid all issues). Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Another EMM386 release, bugfixes and enhancements
On Mon, 22 Mar 2004, Michael Devore wrote: > I've tried QuickView Pro and a DOS extended PNG viewer and they both are > documented as using an LFB and work fine under EMM386, so we're dealing > with something beyond a simple LFB existence problem here. that's right. Quake also works in LFB modes (except it didn't startup for me with NOEMS set, but that's a different issue and we already discussed that anyway). > I've thrown about everything I could at this Duke3D high res display > problem. Downloaded and installed 386SWAT debugger and modified EMM386 > to work with it, but when 386SWAT is loaded, Duke3D magically starts > working again with EMM386. Very strange. Yes indeed... I can try it in Bochs one day and see what happens, but it's not worth spending any more hours debugging for you then for the time being, agreed. Well what is "worth" here, of course thanks a lot! Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX/UCL Hell
On Mon, 22 Mar 2004, Aitor Santamaría Merino wrote: > I'd like to ask if someone has successfully compiled UPX/UCL. yes, but only on Linux. > of those that I have corrected where due to things such as using > SYSLIMITS.H not being present (it was SYSLIMIT.H, I guess that to follow > DOS 8.3 filename convenction, and makes me wonder how the authors > managed to downloaded a DJGPP distro and compiler it themselves?) you have to be very careful with unzipping DJGPP. If you use DJGPP on a system with LFNs enabled then you have to unzip with an LFN enabled unzipper (like the unzip32.exe that comes with DJGPP). In that case SYSLIMITS.H will be unzipped as SYSLIM~1.H with a corresponding LFN. If you use PKUNZIP 2.04g or a 16 bit UNZIP then SYSLIMITS.H is unzipped as SYSLIMIT.H. If you use DJGPP on FreeDOS (without any LFNDOS or similar) then you can use the 16bit UNZIP, and it will look for syslimits.h, syslimits.h is truncated to SYSLIMIT.H by the FreeDOS kernel and it'll work. > g:/djgpp/lang/cxx/3.33/new:42:21: exception: No such file or directory Most likely a file "exception" does not exist and you have a file "exceptio" instead because you used the wrong unzipper. You have two choices 1. Build the thing in FreeDOS. You didn't specify the OS you were building in, so I must assume it's FreeDOS, so I don't understand but anyway. 2. Re-unzip your DJGPP zipfiles using unzip32.exe in the same OS you are building UPX-UCL. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel [...] dsk.c,1.35,1.36
On Mon, 22 Mar 2004, Luchezar Georgiev wrote: > > if (hd(pddt->ddt_descflags) && !(pddt->ddt_descflags & DF_CHANGELINE)) > > Thanks! As hd(x) is #defined as ((x) & DF_FIXED), the above can be > optimised to: > > if ((pddt->ddt_descflags & (DF_FIXED | DF_CHANGELINE)) == DF_FIXED) Hmm, looks like I applied that change by accident :( As the int13/ah=16 doesn't apply to floppies... Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX/UCL Hell
On Mon, 22 Mar 2004, tom ehlert wrote: > ASM> But anyway, and in order to avoid discrepancies, I'd like to use UPX/UCL > ASM> if available > > Seems GPL forces you to use second best choice > (similar to choosing LINUX) Hmm. What's the best choice then? Solaris? FreeBSD? FreeDOS? For whom? :) But then I don't consider Windows 98 and FreeDOS alternatives to Linux as they fill different niches. Windows NT+ may be an alternative but it depends on what you use the computer for of course -- I would have to install a *lot* of extra 3rd party software such as Cygwin to be able to use it effectively but then I'm not a normal home user. > However, after rereading the *exact* GPL terms, I still consider an > exepacker kind of runtime library. > > IFF >it's ok to compile a GPL program with any compiler of your choice, >and distribute it, > THEN >it's also ok to exepack it with your exepacker >of choice. > > (starting another variant of this nonsense thread) IMHO it's such a grey area that only lawyers can decide... Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] http://freedos.sourceforge.net/ (fwd)
Just wondering, there is duplicate effort involved in having newsitems at www.freedos.org *and* freedos.sf.net and there's already way too much boring cannot-be-automated stuff involved for each release. Can't they be merged somehow? -- Forwarded message -- Date: Tue, 23 Mar 2004 16:56:59 +0100 (MET) From: Eric Auer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: http://freedos.sourceforge.net/ Hi, to avoid confused users downloading FreeDOS 2032 as "last stable release" or something, could you place an "FreeDOS kernel 2033 released" news item on http://freedos.sourceforge.net/ ? Eric. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] http://freedos.sourceforge.net/ (fwd)
On Tue, 23 Mar 2004, Jim Hall wrote: > However, there's the issue of placement on the FreeDOS.org page. If I > include these on the FreeDOS.org main page, I'm afraid the page will > become *huge*. I can create a sample index page if you'd like to see it > - actually, that's something I'd like to see. Maybe that means I reduce > the number of FreeDOS.org news items down to 5 or something. I don't know. > > Ideas? Suggestions? how about simply having the main FreeDOS news items on the freedos.sf.net page? There really isn't much value IMHO for the news items on freedos.sf.net, all it causes is to have a (more or less) duplicate of http://sourceforge.net/project/showfiles.php?group_id=5109 and it causes Eric to send me emails if I don't update it. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
On Thu, 25 Mar 2004, Luchezar Georgiev wrote: > Thanks, Aitor! > > 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm > As far as I know, APPEND is considered dangerous and incompatible. It had > better stay missing. > I think that SCANDISK is the most important missing program. it may be important, but I respectfully disagree it being a showstopper. The FreeDOS spec still states that we should be compatible with MSDOS 3.3. Scandisk is beyond 3.3 FAT32 support is beyond 3.3 even support for hard drives > 32 MB is beyond 3.3 -- it's cool that we have the last two features but they're not required by our self-imposed plans. so, if anything FAT32 related is going to stop 1.0 then either the spec should be changed or 1.0 will be released a lot later. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS EMM386 praise
On Fri, 26 Mar 2004, Michael Devore wrote: > There was a bug in EMM386. Map multiple pages, EMS 4.0 function 50h, > was broken. I fixed that and Lemmings runs for me. Cute game, although > I cannot play well enough to save any of them. Those poor lemmings :-( Anyway, just an ACK that all problems I reported were solved in the RC, inc. hello.exe (and Quake, FreePascal, same problem), and Duke3d 800x600. Thanks Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
On Thu, 25 Mar 2004, Gregory Pietsch wrote: > i (insert mode) - implemented. I made the get-out-of-insert-mode > character a period on an otherwise blank line instead of control-Z > because the one thing I hated about MS edlin was the use of control > characters in the syntax. (The period can be escaped if you really > wanted just a period on a line.) isn't it possible to accept ^Z too? I've had a report of somebody fighting with edlin because he didn't know it was "." instead of ^Z... And then the only way to escape is to try all keys or to reboot... Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOSFSCK >2G FAT32 bugs fixed!
On Wed, 31 Mar 2004, Luchezar Georgiev wrote: > > Oops! VolumeSeek() should be loff_t(loff_t offset) instead of off_t > > VolumeSeek(off_t offset)! But there must be yet another bug, because > > when I changed it, the bug was still there, although the code generated > > for VolumeSeek() became correct. Will try to catch the other bug > > tomorrow. > > Caught it! VolumeSeek() wasn't declared anywhere so its return type was > assimed int. See patch. Hmm. Sorry I didn't check out how dosfsck is compiled but perhaps you should compile with the GCC -Wall -Wstrict-prototypes options. -Wmissing-declarations may also come in handy -Wnested-externs sometimes too but it depends on your codingstyle. We use these four for DOSEMU and it catches quite a few of these kinds of errors. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] MUF (Microsoft's Undocumented Features)
On Thu, 1 Apr 2004, Luchezar Georgiev wrote: > Things like that are Megalo$0ft's favourite "trick"! Here's what Pat > Villani (the author of DOS/C on which our kernel is based) wrote about the > Microsoft's love to undocumented features: > > > there is constant debate over Microsoft's use of undocumented features > > in MS-DOS, Windows and now Windows95. In all fairness to Microsoft, I've > > seen other operating systems that also have undocumented interfaces. My > > opinion is that programmers should avoid these whenever possible. > > However, Microsoft did go to extremes to hide key features and I fault > > them for this. You don't go out of your way to hide these key features > > unless you are actively trying to lock out competition. > > So the result is: "Ein Volk, ein Reich (Microsoft), ein Führer (William > Henry Gates III)!" :-( Hmm -- that won't stop you using MS Windows though... User-Agent: Opera7.23/Win32 M2 build 3227 Think before you write, such comments can only be counter-productive, as such comparisons invoke Godwin's law so the thread is over http://www.killfile.org/faqs/godwin.html Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel version
On Fri, 2 Apr 2004, Arkady V.Belousov wrote: > 1-áÐÒ-2004 20:55 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to > [EMAIL PROTECTED]: > > LG> Adding *strings* just for information purposes in the precious resident > LG> space is a bad idea. > > Lucho, you blindly skip all my mentions about os_release. :( I mention > this variable (and subfunction 0xFF) in freedos-kernel@ when report reduced > size (after my patch), I quote here excerpt from sources about this > variable... And now you say that this is bad idea (when you say nothing > earlier)?! This string can't be removed -- it's part of RBIL: D-2133FF- INT 21 - FreeDOS - GET DOS-C/FREEDOS KERNEL RELEASE STRING POINTER AX = 33FFh Return: DX:AX -> string of the form "FreeDOS kernel version " KERNEL_VERSION_STRING " (Build " KERNEL_BUILD_STRING ") [" __DATE__ " " __TIME__ "]\n" I sent this to Ralf Brown at the time that Matthias Paul did a desperate call for updates because RBIL62 could be released any day (that was in Apr 2002), seems I missed that release though. I really object to breaking backwards compatibility here; we already had this function when Pat was still maintaining the kernel... But indeed. Adding strings is not good. So I won't add any new strings. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kernel version
On Fri, 2 Apr 2004, Arkady V.Belousov wrote: > PS: Why you not answer for previous time? because at this point it seems to interest more people than just you. I just cannot answer every question, or I wouldn't have any social life left... > PPS: Do you report bugs in RBIL (eg, D-216C00) to Ralf? not the one in 216c00 -- I won't spend any effort on this anymore since there hasn't been a release for almost 4 years now. I did about the confusing EOF bit in 214400, also around April 2002. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Ralf Brown's interrupt list 62 will never be released? (was: Kernel version)
On Fri, 2 Apr 2004, Luchezar Georgiev wrote: > On Thu, 1 Apr 2004 21:46:29 +0100 (BST), Bart Oldeman wrote: > > > I sent this to Ralf Brown at the time that Matthias Paul did a desperate > > call for updates because RBIL62 could be released any day (that was in > > April 2002), > > On 1st of April? ;-) Hmm -- 19 Feb. http://marc.theaimsgroup.com/?l=freedos-dev&m=101409720018452&w=2 > But since nobody knows of that function (because the information about it > was never publicly released in the RBIL), its removal won't break > anything! Or do I miss something? http://marc.theaimsgroup.com/?l=freedos-dev&m=103714414728398&w=2 > Alas, the RBIL has not been updated for the last 4 years, and will never > be anymore :-( did Ralf Brown tell you that? Any other source, other then just speculating from having no updates? Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64 testing info/requests
On Wed, 14 Apr 2004, tom ehlert wrote: > Hello Michael, > > MD> Additionally, if any port 92h related > MD> lockups happen, I'll move "always-on" to top the A20 test list, > MD> see if they go away. > > *** PRO 'always-on' *** I think "always on" here refers to machines that *boot* with A20 enabled. In that case (after doing the "rep cmpsw" style test) the Linux kernel finds itself lucky and doesn't have to do anything. The idea being that if you boot with A20 enabled then A20 toggling isn't likely to work at all. We of course, unlike the Linux kernel, need to be able to turn A20 off for the braindead reasons that were mentioned before -- and that's probably not possible on such machines and then you just have to live with that. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [announce] mem 1.5
MEM 1.5 is up for grabs at http://freedos.sf.net/mem/mem15.zip User visible changes are: * implemented mem /c at popular request * detect EMS memory if an EMS driver is present without a page frame (with FreeDOS "EMM386 NOEMS"), no longer reporing "EMS Internal Error". * made output more MS compatible, also reporting the amount of extended memory if no XMS driver is present * fixed a couple of issues in the "mem /f" output; it now also detects the relocated Extended BIOS Data Area (EBDA), the drive data table and a sector buffer. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bart's mem 1.5
On Sat, 17 Apr 2004, Arkady V.Belousov wrote: > - bug in .lsm: "Entered-Date: 17APR2003". Jim, can you correct this in the published LSM? It's a bit pointless to release mem 1.6 just to correct the LSM date. > - check_name() uppercases MCB.name. As result, instead "win386" we get > "WIN386". well WIN386 doesn't run on FreeDOS so that's kind of a non issue. > - "do NOT count MEM environment as free space" - why? Memory, currently used > for MEM, will NOT substracted from memory, which will be used for > subsequent programs call, so you get wrong "free/largest" value, if will > count MEM memory as "non-free". There is no why -- it's just the same thing that MS MEM does. So for compatibility I'm doing it as well -- otherwise MS MEM gives a different value than FD MEM which is very strange. Also a new program that is loaded will have the same environment size that MEM has so in that way it make sense. > - "don't merge free blocks in the output anymore" - why? Splitted free > blocks anyway (should be) joined by DOS, so for user is uninterested that > at given time some free block is splitted. Same here -- compatibility with MS "MEM /d". Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bart's mem 1.5
On Sat, 17 Apr 2004, Bernd Blaauw wrote: > and what's with the "add 80KB"? > FD-MEM: SYSTEM99,536 (97K) 12,480 (12K) 87,056 (85K) > MS-MEM: SYSTEM 17,600 (17K) 12,480 (12K) 5,120(5K) > > FD-MEM: Upper 240K 106K 134K > MS-MEM: Upper 163,82426,624 137,200 hmm. please run FD "mem /f". Otherwise it's difficult to see. This doesn't occur for me. As it's exactly 80K there may be a hole in your UMBs somewhere -- stupidly I missed that case. Won't be difficult to fix. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [announce] mem 1.6
Thanks for the feedback: MEM 1.6 is now available: http://freedos.sourceforge.net/mem/mem16.zip Changes: * minor output tweaks, don't upcase names anymore * try to detect UMB holes and don't count them as upper memory * display UMB holes as "reserved" in mem/f output * display version number for "mem/?" Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] [announce] mem 1.6
Thanks for the feedback: MEM 1.6 is now available: http://freedos.sourceforge.net/mem/mem16.zip Changes: * minor output tweaks, don't upcase names anymore * try to detect UMB holes and don't count them as upper memory * display UMB holes as "reserved" in mem/f output * display version number for "mem/?" Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Recent Bugzilla entries
On Mon, 19 Apr 2004, Eric Auer wrote: > Hi, as FreeDOS 2034 is out, does it make attempts to fix > http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1745 ? > "renaming dir with trailing backslash makes it vanish" which could be > blamed on shell, kernel or both? [...] Eric, anyone can look through the bug list, and your mail doesn't give much more information than that. It would be much more helpful if you could actually *check* yourself if 2034 fixes these bugs rather than stating the obvious. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: Re: [Freedos-devel] Recent Bugzilla entries
On Mon, 19 Apr 2004, Eric Auer wrote: > Hi, I could check SOME of the problems, but I assume that you > already KNOW which of them you have addressed and can give a > comment about that question on the list first. Don't assume. Any comments will end up in Bugzilla itself. If there aren't any it means there aren't because I haven't looked at it at all. By posting to the list you are counter-productive -- by asking others to do something for you that you haven't tried yourself even if you would be able to, you will just piss them off at some stage (excuse the language, but that's how it feels like for me -- dunno about others) Sure some problems require software you don't have but then there's plenty left -- and here's the crux. > I am thinking about LBAcache floppy caching problems, > maybe you have some hints on that, too: Are there programs which > assume that a floppy access (read / write, int 13) can ever wrap > around a track boundary? I don't know. > Are there programs which assume that you can access a floppy through > LBA functions? I don't know. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: FreeDOS Beta9 RC5 has been released
On Tue, 20 Apr 2004, Eric Auer wrote: > This reminds me of the 386 question: How much bigger than the FAT16 > kernel is the FAT32 kernel in RAM (low, umb, hma) and how much of > this would be saved by optimizing for 386, experiences? Low: the drive data tables take 32 bytes more per drive (depends on the number of partitions you have, independent of LASTDRIVE) The 2 low fnodes take 6 bytes more for FAT32 (12 bytes total) HMA:HEX DEC 8086 80186 80386 8086 80186 80386 FAT16 995c 9694 94c5 39260 38548 38085 FAT32 a7cb a4ed a24a 42955 42221 41546 i.e. FAT32 adds ~3.5-3.7K; 386 optimizes out ~1.2-1.4K The fnodes take 6 bytes more (6 * #FILES) UMB no difference > How about speed gain? Perhaps, sometimes 1, 2 or 3 more BUFFERS available can make a difference. Otherwise I can't see any visible speed difference. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
