I finally figure out what happens with my posts! They are sent to the list but not to me! Neither has this reply of Bart been sent to me! Surely there are some problems but where? I don't know :-(
hmm FREE is quite limited here -- being only redistributable for personal use. For Bulgaria it seems to make no difference at all anyway.
;-) You see that all those license issues are very hard to understand to me. (But I keep trying!) And I guess this will be so until I get arrested some day, which will finally prove that Bulgaria has become a really NAZIvillized country at last! ;-G
anyway, the main advantage of turbo c 2.01 and c++ 1.01 over watcom is that these compilers are fast and small. What kind of advantage is there for borland c++ 5.2 then? Does it run on XTs too (Eric seems to make a big point about that)? Is it just as small?
Borland C++ 3.1, 4.0, 4.52, and 5.2 (all tested!) require a 386 and work in DOS. Some files of the latter need patching with WDOSX but it does the job! Of course it's not as small as Turbo C, but the necessary minium file set occupies 11 MB on disk (vs 16 MB by Open Watcom).
About smaller compressed kernels, did you try "-od" with Watcom? Surely that will bloat the kernel size a bit but should also decrease the entropy and therefore enable smaller compressed kernels.
It overflows the 64K size limit and can't be used! That's how great Watcom optimisations are ;-)
I already knew that turbo c 2.01 compressed kernels are smaller than the watcom equivalents.
Borland C++ 4.52 builds the smallest compressed kernel - just 41.6 KB for 80386 & FAT32 b.2033 ;-)
Perhaps you can see if the printf problem you encountered also happens for one of turbo c 2.01 or turbo c++ 1.01. That would at least enable me to easily reproduce it.
No, it doesn't happen there, neither does it happen if I compile for 80186 with Borland C++! :-(
Nobody suggests that we switch to Borland. But it's one of the supported compilers so I don't think it should be ignored. So please, still consider my patches and let's hope I can fix the printf thing too. By the way, even with this printf, it still hangs on a different INSTALL= configuration :-( But of course the debug kernel doesn't hang! The invalid opcode message prints some sequence of zeros in the stack. Does this ring some bells in you?
Lucho
------------------------------------------------------- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
