Hi, while it would definitely take a lot more than a few minutes for me to install OpenWatcom and compile a new kernel (always using Turbo C for that until now), luckily Jeremy already did the test. Thanks for that!
> My question is, does any other software destroy important registers? A comment in the kernel source code tells that the "bloody fucking" (sic!) RTSND driver changes SI and DI during the driver strategy call. The required workaround eats 4 bytes of precious stack and 4 bytes of low RAM. Note that I still recommend to change EXECRHM to preserve ES, as it is not clear to me why EXECRHM is assumed to be allowed to change that, which it does at the moment. > I think, this is bad direction: if some external program unexpectedly > modifies nondeclared registers/parts (unimportant, syncronously (exoplicit > call) or asynchronously (hardware interrupt)), then should be fixed external > program, not added extra code into kernel. Especially, saving registers eats > prceious stack, whereas fd-emm386 _may_ be fixed without big efforts. I agree that device drivers should not modify any register when you call them, but I admit that I do not remember WHERE I have read that device drivers MUST not modify any registers. In particular, fixing EMM386 would be pretty easy for those who have SY3PACK and all required compilers. For the moment, EMM386 would only need extra push/pop for FS and GS in the go_driver_entry code, because somebody stated in the kernel source code that OpenWatcom is not yet able to use 32bit registers like EAX. However, I would really recommend to modify go_driver_entry to save eax ebx ... ebp instead of the current ax bx ... bp, as better compilers WILL cause the kernel to use those registers. Of course then you could STILL work around by declaring execrh as "changes all registers", but that would really hurt performance as execrh is used for ALL device driver calls, not only for init_device. Eric PS: Just if you have wondered, HIMEM already does save all registers around the init call, including the 32bit ones, but does so before checking if the CPU is 386 or better... Checking first and jumping directly to "init failed" instead of calling the init code when a pre-386 is detected would be an idea (although you have to split the LSS in SY3PACK into MOV SS... / MOV SP..., "wasting" 5 bytes of disk space, to make the SY3PACK stub 186+ compatible). Talking about HIMEM: please make the version number BCD as recommended in RBIL, as some programs do not display "3.0b" (binary) correctly as 3.11 ;-). ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
