Hi! I recommend to move this discussion to freedos-devel, with a nice subject line.
So here some information about UPX: UPXed SYS can crash when loaded into a too small memory area (only UMBs are typical cases of small memory areas, so the problem arises only with UMBs in most cases). This is due to structure of SYS and cannot easily be fixed. Maybe Toms SY2PACK for SYS-EXE is better here. UPXed COM check the stack pointer at start time before unpacking. If the COM is loaded into a < 64k memory block and the memory block is too small for the unpacked version, INT 20 is called (give up, no error message, errorlevel 0). UPXed EXE simply leave the memory requirements info in the exe header intact. That way you can even tell in the exe header how much heap you need at least and how much heap you will use at most. A non-compressed DISPLAY driver will fail to fit into a small memory area, and LH / DEVICEHIGH can then load low as a fallback. However, this wastes disk space. An EXE version avoids that. Another option - and I prefer that one - is to use a compressed COM and check if there is enough memory dynamically. THEN, simply load DISPLAY TWICE, once HIGH and then LOW. The loading low will fail if the loading high has worked, because DISPLAY has a protection against double install. If you do not like failure without error message, use an UNCOMPRESSED DISPLAY but STILL allocate the buffers dynamically. Then you avoid the silent failure which can happen with UPX *and* you still save most of the disk space because you allocate buffers dynamically! The latter suggestion is especially important if you want to make DISPLAY a real DEVICE. Other than an EXE (with heap specification in the header), the SYS would have to be an huge file, 60k or something, unless you allocate the buffers dynamically. However, I read your recommended reading about NLSFUNC, and there is no imperative need that DISPLAY would be a device anyway. NLSFUNC in a nutshell: 1. COUNTRY... tells kernel about country, hardware codepage, country file 2. you load DISPLAY which can load codepages into video hardware 3. you load KEYB which can process codepages for keyboard 4. you load PRINTER which can process fonts / char substitution to support codepages for printers 5. you optionally load other codepage stuff 6. you load NLSFUNC 7. you do CHCP. CHCP sends a codepage change request to the kernel. The 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. 8. the kernel is happy and asks NLSFUNC to spread the word. NLSFUNC surfs the DEVICE list and tells all DEVICES which support the IOCTL about the codepage change. It also tells DISPLAY and PRINTER but not KEYB. 9. DISPLAY tells KEYB about the change and changes the hardware font. To be able to do so, you have to have run MODE CON CP PREPARE... before, to send the font data from CPI/CPX to DISPLAY. No idea why this nutty scheme was invented but I guess we have to stick to most of it. Without NLSFUNC, you can: - use MODE CON CP SELECT to update DISPLAY / KEYB status - use COUNTRY to select country settings from currently kernel-builtin tables - tell KEYB directly about settings at startup But you cannot tell the kernel to update the codepage that way, nor can you tell PRINTER. So in THAT case, you have to tell the kernel that the hardware codepage would be the codepage which you trigger later in DISPLAY and live in half-sane state until you actually load DISPLAY and run MODE. I think the kernel does not even have codepage selection yet, because the tables would be too big without an external country sys file. So you only have the ability to set NLS info by country code yet. As you can see, NLSFUNC is a lot of glue code, a device chain surfer and a country sys file parser. Would be cool if somebody would volunteer to start working on it ;-). Eric. PS: This was "kernel problems and problem loading high DISPLAY" on freedos-kernel before. But I think it is not a kernel problem. PPS: UPX does NOT try to enlarge the memory block for COM. It just checks if it IS already big enough. For SYS, it does not check anything at all because only AFTER decompression the driver gets TOLD how big the memory block is and is then allowed to SHRINK it. ------------------------------------------------------- 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
