Hello Steffen, > Sorry it took so long.
No problem, I suppose that you are busy. (For the list: This is a reply to a message I sent to Steffen off the list and that I've attached to the end of this one) > Honestly, I would like to: > > a) either get my whole distribution off the kernel or A bit too drastical, I would say... > b) get in touch with you about the internals and the design decissions. I've not asked you about this before because I wanted to learn more about the current implementation before bothering you with silly questions, but I'll be more than happy to start the discussion. Right now, I've made a first implementation of MUX-14-02 and MUX-14-04 (Get Extended Country Info and Get Country Info) which I believe that are functionally correct, although there is room for optimizations. These functions (the whole NLSFUNC, in fact) relay on a working implementation of MUX-12-26 to MUX-12-29 (Internal Open, Close, Seek and Read). I have implemented them to test NLSFUNC, but Tom Ehlert warned that they are using, and probably overrunning, the kernel stack, so they are not valid for real life. Unfortunately, my poor knowledge of the kernel internals does not allow me to fix it myself. If I've understood your NLS implementation correctly, MUX-14-01 and MUX-14-03 (Change Code Page & Set Code Page) should both read the info for the country-cp pair from COUNTRY.SYS (in fact, MS-DOS MUX-14-03 ignores the cp even if cp != -1 and loads the info for the first country code match), allocate enough memory, populate the nlsPackage structure (including all the tables that are relevant), add it to the chain in the nlsInfoBlock, and point actPkg to it. Then, MUX-14-01 will inform the relevant drivers issuing the necessary ioctls. I understand that sysCodePage should not be updated (?) The internal ioctl (MUX-12-2B) is not yet implemented, but it seems easy once (if) the stack problem is solved. I do not know yet how to allocate memory from within these functions, as they are called by the kernel itself and so it is not possible to use the int21 functions. MUX-14-00 is trivial and implemented. For the rest of MUX-14 functions, I've not yet looked at them, but they seem to be easy to implement. nlsYesNo() will require a COUNTRY.SYS extension, though. Anyway, what is the reason for pushing nlsYesNo(), nlsUpMem() and nlsUpFMem() through the mux? Regards, Eduardo. --------------------------- Eduardo Casino wrote: Hi Steffen, There's still a problem with your suggestion (and with present searchPackage() ). As default values are resolved _inside_ the function, they are not propagated correctly to the mux functions if searchPackage() returns NULL. A simple solution could be to pass cp and cntry by reference to searchPackage(). What do you think? Eduardo. ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
