Hi, I have some extra questions... > Another option - and I > >prefer that one - is to use a compressed COM and check if there is enough > >memory dynamically. > If by dynamically you mean that DISPLAY should check that, I am open to > admit patches, of course.
If you mean in the COM version: The test is simple. if SP < (end_of_code + amount_of_required_head) then "not enough memory" If you mean in the EXE version: Define in the headers instead, plus use malloc. If you mean in the SYS version: The problem is only with UPX. Without UPX, DOS will tell INIT what the latest allowed end-of-driver byte is, and INIT replies to DOS what the actual end-of-driver byte is (possible equal to begin-of-driver if driver does not go resident). > The init command of a device driver contains a break address. I *ignore* > if I can enlarge this pointer and so make DISPLAY as big as I need... No, as told, you can only LOWER but not RAISE the break address. > > kernel asks NLSFUNC to analyze the codepage file. NLSFUNC uses int 2f.12 > > file I/O to read the file and sends back info to the kernel. > Are you sure that NLSFUNC will do file i/o 'hot'? remember you are in-DOS. It does. It was stated in that very long mail which you forwared me. The kernel only stores the filename, but NLSFUNC uses int 2f.12 file i/o ... because it cannot use int 21 file i/o because you are in-DOS. > The scheme is sensible, so that you can change the global codepage of > the system and all its components. You could conceiveable have an alternate scheme where CHCP has to load country,sys into a buffer and tell the kernel to do the rest itself. And one of the weird points of NLSFUNC operation is all the passing of information back and forth, sometimes even indirectly (DISPLAY->KEYB). > This is a good reason why DISPLAY/PRINTER have to be SYS, and in such > case you can use > MODE xxx CODEPAGE.... You can adjust MODE to work with a non-SYS DISPLAY. Current MODE does that. As MODE / NLSFUNC are the only tools which try to talk to DISPLAY / PRINTER, we have nothing to lose. Well, with DISPLAY.COM / PRINTER.COM, for example, MS NLSFUNC and MS MODE codepage functions would not work. But hey, those ship with MS DOS anyway! > So how is that this works under MS-DOS correctly (and DISPLAY is loaded > low) and doesn't in FreeDOS? No idea, I need more details. MS DOS LH certainly does not analyze if the program stays in RAM and if not runs it again in low RAM. To test, you can try "LH EECHO.COM Hello world". It would show Hello world twice if LH would have that "did it stay resident?" check. If MS DOS LH always insists on reserving 64k UMB for each COM program or else loads low, MS DOS LH would be pretty useless. Maybe there is a command line option for that, though. LH will allocate [size of file + PSP size + a bit of stack] for COM files, and only if not even that much UMB space is free it will load low. This means that UPXed display will be loaded into UMB and *then* the UPX stub will abort loading due to lack of memory. But LH will not notice! Not even MS LH if you ask me. Eric. PS: I might bore you, but I think a good method - because of the double load protection - is to use LH DISPLAY DISPLAY ... If this crashes, then there is a bug in LH (i.e. it fails to move the stack top into valid range when < 64k are free). ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
