[Freedos-devel] Re: [Freedos-cvs] kernel/kernel int2f.asm,1.33,1.34
Hi! 4--2004 10:16 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: Clean up int2f assembly a bit (merge some common bits, clarify label names) Long awaited action. :) +++ int2f.asm 4 May 2004 10:16:45 - 1.34 +jnc ret_set_ax_to_cx +ret_neg_ax: neg ax +ret_int2f: pop di pop si pop bp ret +ret_set_ax_to_cx: ; ext_open or rw - status from CX in AX + ; otherwise CX was set to zero above +xchgax, cx ; set ax:=cx (one byte shorter than mov) +jmp short ret_int2f jnc ret_set_ax_to_cx ret_neg_ax: neg ax xchgcx,ax ret_set_ax_to_cx: xchgax,cx ret_int2f: pop ... ret --- 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_id149alloc_id66op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.30,1.31 fatfs.c,1.66,1.67
tom ehlert wrote: Hello Arkady, + wasfree = 0; + if (cluster == FREE) +wasfree = 1; wasfree = cluster == FREE; well - we know that gifted russian programmers can read this cryptic stuff fluently. mortal programmers like me prefer a more readable style. tom wasfree = (cluster == FREE); ? (That's how I'd prolly have written it myself, and I'm not really much of a programmer) -uso. --- 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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeDOS history check: LBA, FAT32?
Hi, the maintainer of http://www.mwpms.uklinux.net/page1.htm wants to know when we introduced FAT32 (2029??), LBA (2025 by Tom 2001?), Flash booting (I think it will work if FAT formatted?), ROM booting (does ROMOS work reliably?) ... I suggested that he updates his page but my suggestion mail contained too many I think we introduced [feature] with [version] and not enough I KNOW Eric --- 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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: OT: Guess who gives a damn about human rights
Hi, as said, I know that GPL cannot limit use of free software. You may remember that I took part in this discussion a while ago. I had the example Is OpenOffice.org on the PC of a spy using software for non-human-friendly purposes? Answer: You cannot decide. So I am not pissed about US politics as Eric the programmer. I am pissed as Eric the human. Eric If you like it, you may stop shipping free software bug RMS definition, and start developing freedom software which cannot be used to harm other people. I know this sentence sounds USA... but trust me I understand you... PS: As said as well, the other FreeDOS programmers are humans, too, so they can have an opinion about human rights. And enough people with an opinion means that politicians MIGHT eventually start to listen to them and start to behave as humans, too. PPS: I read about the impressive performance of IL secret service when they wiretapped the wiretappers of NL secret service... grin. diego, kde-il translation team --- 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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] LH DISPLAY problems / NLSFUNC in a nutshell
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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] LH DISPLAY problems / NLSFUNC in a nutshell
Eric Auer wrote: Hi! I recommend to move this discussion to freedos-devel, with a nice subject line. So here some information about UPX: how easy is it to prepare DISPLAY for COM2EXE as Arkady suggests? still, why would LH not abort on MSDOS but abort on freedos kernel? FreeCOM is being used as shell on both platforms. and I have seen FreeCOM crash, so I do think there's some UMB problem, but I (still) need to prepare a testcase for the kernelpeople, so they can easily verify. Bernd --- 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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] LH DISPLAY problems / NLSFUNC in a nutshell
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. or you use .EXE style sys-files, of course. PS: This was kernel problems and problem loading high DISPLAY on freedos-kernel before. But I think it is not a kernel problem. I may be wrong, but I seem to remember, that MSDOS allocates at least 64k for .COM style programs. If that would be the case, MSDOS would load DISPLAY silently low. Not even sure if FreeDOS tries to load into small upper memory blocks. tom --- 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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Smaller SHARE tool for testing
Hi, please check http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ freedos-share-04may2004.zip I replaced the fprintf by write and turned SHARE.EXE into a 3k smaller SHARE.COM ... especially the memory footprint is 3k smaller now, too. Even smaller would it be if the init part could be dropped from RAM, but this is a tool which is written in C so I do not know how to implement that. For default parameters (20*13bytes for lock areas, 2048 bytes for 136 byte sized file descriptions) SHARE now uses 9.7k of RAM. Could be much less, compare to MS SHARE. Maybe somebody can help with this. And notice that MS are telling in KB article KB161619 that SHARE is not compatible to FAT32 kernels. Maybe we have to add something to our SHARE here. I think normal FAT16 compatible file functions of DOS should cooperate with SHARE even for FAT32. Eric. PS: I hope SHARE still works properly after the change! --- 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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: LH DISPLAY problems / NLSFUNC in a nutshell
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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] OT: Guess who gives a damn about human rights
On Tue, 4 May 2004 17:35:22 +0200 (MEST), you wrote: Sorry for off topic. Eric, Try World Lingo: http://www.worldlingo.com/products_services/worldlingo_translator.html Guys: FreeDOS is great, but some aspects of US politics suck BIG TIME. I think we should try to keep FreeDOS over the politics, that means we declare ourselves not directly related to the policies or party that involved in the warfare. We can't stop them using FreeDOS for the military because once involved with this kind of organization, they're outside the control of law. IMO, keep away from nationalism. I didn't feel a thing when prime minister of China visit Germany, very annoying and uninteresting topics ... the real thing is weapon again, tired. Let the US citizens take care about their country. Rgds, Johnson. --- 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_id149alloc_id66op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] debug 0.95f and 0.98 'Unexpected single-step interrupt'
To: [EMAIL PROTECTED] From: Arkady V.Belousov [EMAIL PROTECTED] Subject: Re: [Freedos-devel] debug 0.95f and 0.98 'Unexpected single-step interrupt' Date: Tue, 4 May 2004 15:42:29 +0400 (MSD) Hi! Try this: __O\_/_\_/O__ debug a mov ah,4c int 21 int 3 g=100 g _ O/~\ /~\O OK, I've tried it. Under MS-DOS 2.1 with native DEBUG and Win XP with native DEBUG, it drops you out of DEBUG and back into COMMAND.COM. In a way this makes sense, since the above code terminates a program and since you haven't loaded a program into DEBUG the only program that DOS (or XP) could possibly terminate is DEBUG itself. Under MS-DOS 2.1 with fd-debug, you're back at the DEBUG prompt. Under dosemu 1.2.1 and FreeDOS (I don't know what FD version, sorry, but kernel.sys was dated 31 January 2004), I get Unexpected single-step interrupt. So. Are you saying that the behavior under MS-DOS 2.1 is buggy? I strongly suspect that the buggy behavior under FreeDOS is either the problem of dosemu or freedos. --Paul Vojta, [EMAIL PROTECTED] --- 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=3149alloc_id=8166op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
