Eric Auer escribi�:
If by dynamically you mean that DISPLAY should check that, I am open to admit patches, of course.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 thenMy own preference is not to touch it much until it is made a SYS device driver and gets finished (2 versions more), but otherwise, I'd stick to Tom's suggestion of making it an exe in version 0.11 (don't have it for granted, but will try!). Of course, I'd make a single segmented program, on which start I'd simply set DS pointing to CS (and maybe creating a small stack).
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!
I might have missed Arkady's suggestion, but I am new to COM2EXE (I guess that the program would do what I described above), where can I find COM2EXE?
The latter suggestion is especially important if you want to makeThe 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. The problem is that I don't know beforehand how many buffers the user wants to allocate.
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 isFor the simplicity of NLSFUNC, it is....
no imperative need that DISPLAY would be a device anyway.
NLSFUNC in a nutshell:KERNEL codepage, not hardware codepage. It tells the codepage for the collating tables and such.
1. COUNTRY... tells kernel about country, hardware codepage, country file
7. you do CHCP. CHCP sends a codepage change request to the kernel. TheAre you sure that NLSFUNC will do file i/o 'hot'? remember you are in-DOS.
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.
The end the only thing I ignore is in which moment the alternative collating tables for other codepages are loaded from COUNTRY.SYS.
It could be done by kernel during COUNTRY=, or perhaps by NLSFUNC (which is rare, as you don't specify a filename/location to COUNTRY.SYS)
The scheme is sensible, so that you can change the global codepage of the system and all its components.No idea why this nutty scheme was invented but I guess we have to stick to most of it.
Without NLSFUNC, you can:so you loose to risk data every time you change to a codepage which is different from kernel codepage (collating tables are not updated).
- use MODE CON CP SELECT to update DISPLAY / KEYB status
But you cannot tell the kernel to update the codepage that way, nor can youThis is a good reason why DISPLAY/PRINTER have to be SYS, and in such case you can use
tell PRINTER.
MODE xxx CODEPAGE....
PS: This was "kernel problems and problem loading high DISPLAY" onSo how is that this works under MS-DOS correctly (and DISPLAY is loaded low) and doesn't in FreeDOS?
freedos-kernel before. But I think it is not a kernel problem.
Aitor
-------------------------------------------------------
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
