Re: [Freedos-devel] [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
Hi! 21-Авг-2006 22:00 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to "tom ehlert" <[EMAIL PROTECTED]>, freedos-devel@lists.sourceforge.net: >> > always wondered why, at 0 cost, EMM386 cannot be loaded from >> > commandline. >> DOS won't see UMB's then AS> Yes, this means you don't get this benefit, but my point was: you AS> don't get any damage. With proper implementation, all should work right. As example, there is xmsmmgr.exe in Win9x distributive setup. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
At 09:49 PM 8/21/2006 +0200, tom ehlert wrote: >b) I was referring to MKEYB anyway ;) > > There would remain the problem of loading EMM AFTER KEYB, >c) EMM386 can have the int15 first always - EMM386 is *the* BOSS >in a virtual environment (it call the real mode int's itself) >d) this would be a problem if emm386 is loaded *before* (m)keyb, and >keyb handles all keys The fix Eric sent for NOALTBOOT seems to make FDAPM happy, at least as far as WARMBOOT (hopefully the rest, too). I don't know if that will clear up all the Ctrl-Alt-Del problems Norbert was having, but it certainly tips the scales back towards keeping NOALTBOOT as the default option. Which is good, because I really didn't want to hook into INT 15h anymore than it already is. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
Hi, 2006/8/21, tom ehlert <[EMAIL PROTECTED]>: > Hello Aitor, > > > For the rare cases in which this should not happen, > > KEYB xx /9 > > does install such handler for int15h (as the rest of KEYB is also > > based in the same principle). > a) KEYB isn't always installed Ok, let me rephrase: "if you are in such trouble (with a very low probability) then you MUST install KEYB. > b) I was referring to MKEYB anyway ;) Yeah, I wasn't. :) > > There would remain the problem of loading EMM AFTER KEYB, > c) EMM386 can have the int15 first always - EMM386 is *the* BOSS > in a virtual environment (it call the real mode int's itself) Yes, but in this case you have to (as KEYB does) write a new handler for int9h to explicitely call int15h, so you are in the same trouble ;-) Now that you mention it, I just wonder if KEYB xx /9 will have troubles in VMWARE (probably). > d) this would be a problem if emm386 is loaded *before* (m)keyb, and > keyb handles all keys Actually few keys are handled by (M)KEYB itself, most are just chained. > > but I've > > always wondered why, at 0 cost, EMM386 cannot be loaded from > > commandline. > DOS won't see UMB's then Yes, this means you don't get this benefit, but my point was: you don't get any damage. Ok, Michael's argument almost convinced me, but it would always be interesting to see how it behaves: you only recommend/support to be loaded as device driver, but you may learn a lot too :) Aitor - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
Hello Aitor, > For the rare cases in which this should not happen, > KEYB xx /9 > does install such handler for int15h (as the rest of KEYB is also > based in the same principle). a) KEYB isn't always installed b) I was referring to MKEYB anyway ;) > There would remain the problem of loading EMM AFTER KEYB, c) EMM386 can have the int15 first always - EMM386 is *the* BOSS in a virtual environment (it call the real mode int's itself) d) this would be a problem if emm386 is loaded *before* (m)keyb, and keyb handles all keys > but I've > always wondered why, at 0 cost, EMM386 cannot be loaded from > commandline. DOS won't see UMB's then Tom - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Compatibility EMM386/HIMEM 2.25 New Release
At 09:41 PM 8/21/2006 +0200, Aitor Santamaría wrote: > > int 15/4f is only supported on AT+ style maschines, but this should be > > true for anything with 386+ CPU's > >For the rare cases in which this should not happen, >KEYB xx /9 >does install such handler for int15h (as the rest of KEYB is also >based in the same principle). >There would remain the problem of loading EMM AFTER KEYB, but I've >always wondered why, at 0 cost, EMM386 cannot be loaded from >commandline. You could and can, it's just not officially supported now because of all the possible effects and potential incompatibilities that making it not first in line at known startup state would introduce. Look at how hard it is to keep everything happy even with those conditions present. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Compatibility EMM386/HIMEM 2.25 New Release
At 09:40 PM 8/21/2006 +0200, Bernd Blaauw wrote: >EMM386 already has the ability to detect Vmware (some magic backport), >so EMM386 can set the proper option (be it ALTBOOT or NOALTBOOT) default >for VMware. The detection ability has been used to exclude some UMB >range previously (and might still be) Yeah, Eric wanted me to tie ALTBOOT defaults to that VMware code. But I don't know of any way to reliably detect Qemu and Ensemble. Plus whatever number of other applications have problems with it. I'll have a chance to check the port thing in an hour or two, see if Qemu and Ensemble work. If I can get those two working with the ALTBOOT code, that will be sufficient to make me reset the default back. At this rate, I'll be on the list until Christmas. Hippie love is already beginning to fade. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
Hi, 2006/8/21, tom ehlert <[EMAIL PROTECTED]>: > it should be possibble to avoid this by NOT doing anything special on > keyboard interrupt, but by doing the same stuff MKEYB does to get > keyboard scancodes: > > intercept interrupt 15, ah=04f, al=scancode > > ... > pushf > cmp ax,4f53 > jne chain_old > > if (ctrl pressed) > if (alt pressed) > BOOT > > ... > chain_old: > jmp [old_int15_handler] > > >jne chain_int15 > > int 15/4f is only supported on AT+ style maschines, but this should be > true for anything with 386+ CPU's For the rare cases in which this should not happen, KEYB xx /9 does install such handler for int15h (as the rest of KEYB is also based in the same principle). There would remain the problem of loading EMM AFTER KEYB, but I've always wondered why, at 0 cost, EMM386 cannot be loaded from commandline. Aitor - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
tom ehlert schreef: > Hello Michael, > > EMM386 already has the ability to detect Vmware (some magic backport), so EMM386 can set the proper option (be it ALTBOOT or NOALTBOOT) default for VMware. The detection ability has been used to exclude some UMB range previously (and might still be) -- Efficiency is intelligent lazyness - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
Hello Michael, > Obviously the best solution would be for everything to work under one > option, but I don't see that happening unless someone can come up with a > good workaround really soon (I wouldn't count on this, but it could > happen). just trying to suggest a solution: kb_keycheck: IN AL,[PORT_A] ; get key-scancode CMP AL,53H; DEL ? JNZ SHORT @@CONT it's possible that all the virtual machines have trouble with the IN AL,[PORT_A] it should be possibble to avoid this by NOT doing anything special on keyboard interrupt, but by doing the same stuff MKEYB does to get keyboard scancodes: intercept interrupt 15, ah=04f, al=scancode ... pushf cmp ax,4f53 jne chain_old if (ctrl pressed) if (alt pressed) BOOT ... chain_old: jmp [old_int15_handler] jne chain_int15 int 15/4f is only supported on AT+ style maschines, but this should be true for anything with 386+ CPU's Tom - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Compatibility EMM386/HIMEM 2.25 New Release
At 02:00 PM 8/21/2006 -0500, I wrote: >Okay, here's where we have a fundamental conflict. It's also causing >problems with FDAPM and WARMBOOT options, perhaps other FDAPM options. It >is the difference between ALTBOOT and NOALTBOOT options in EMM386. Incidentally, if anyone happens to know why the heck FDAPM cares about ALTBOOT, that might be useful knowledge, as well. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
At 09:37 AM 8/21/2006 +0200, Norbert Remmel wrote: >During testing I discovered a bug concerning STR-ALT-DEL usage. >When pressing these keys, freedos crashes with invalid opcode outputting >some memory addresses and registers. >As I remember this wasn't like this using earlier versions of >himem/emm386 but I didn't test so far. Okay, here's where we have a fundamental conflict. It's also causing problems with FDAPM and WARMBOOT options, perhaps other FDAPM options. It is the difference between ALTBOOT and NOALTBOOT options in EMM386. ALTBOOT was the default prior to 2.25 for a while, and NOALTBOOT is the new default, and was the original default when EMM386 was first written up to an unknown version. The problem is that EMM386 no longer hooks and processes the keyboard keys by default to try and force a proper reboot through direct keyboard port access. It leaves things to the default ROM/BIOS reboot code. The keyboard hook happens when ALTBOOT option is active. Some environments and applications can have the machine state set so that a normal ROM/BIOS reboot doesn't work, which is why there is such a thing as ALTBOOT. Unfortunately, a lot of things fail to work, or fail to work correctly if ALTBOOT is active, which is why it was changed to not the default setting in 2.25. Here's a breakdown of the pros and cons: ALTBOOT active positives: All FDAPM options related to rebooting and power-off should work. Some applications may not properly reboot when you press Ctrl-Alt-Del if ALTBOOT is not present. ALTBOOT active negatives: Qemu has an almost unusable keyboard due to frequent loss of status keys, plus missing and doubled keys. VMware is reported to have keyboard or other failure. Ensemble with GEOS will simply lockup during start if ALTBOOT is active -- GEOS doesn't like things hooking and messing with the keyboard interrupt. There are reports from other users that there are additional applications which do not like the keyboard hooked and (pre-)processed this way, but I don't know the exact applications. So here's where we're at: I can either make some environments work properly (or at all) by leaving ALTBOOT as optional as in version 2.25. That means those who are having problems with FDAPM or Ctrl-Alt-Del need to specify ALTBOOT as an option with EMM386. OR, I can switch ALTBOOT back as the default, and Qemu, VMware, and Ensemble users will have to know to specify the option to make their machines work properly. It's not an easy decision, but personally, I think we're better off getting people booted up and running properly as a default (NOALTBOOT), and then telling them if they have problems with FDAPM or Ctrl-Alt-Del to specify ALTBOOT as an EMM386 option. But maybe I'm wrong, if someone can convince me otherwise. Obviously the best solution would be for everything to work under one option, but I don't see that happening unless someone can come up with a good workaround really soon (I wouldn't count on this, but it could happen). Even MS-DOS EMM386 does not use its own ALTBOOT by default, but warns that it may be necessary or desirable for some environments. [technical follow-ups to freedos-devel] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] display exe versus upx versus loading high
Hi! 21-Авг-2006 17:32 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to freedos-devel@lists.sourceforge.net: >> Not need to convert exe/sys to plain sys, especially because combo may >> give additional features (like information about status) without additional >> executables. AS> I was talking of converting COM to SYS. I may try to make it an EXE AS> (in the future a COMBO), but it seems that I won't be saved from UPX AS> greediness. There is two ways: 1. force fixing UPX. 2. convert DISPLAY to plain executable: 2.1. by defining EXE header directly (as data structure) in source (thus, avoiding extra step with COM2EXE); 2.2. or link directly to executable (for TLINK, omit /t option). (1) is useful in any case; (2.1) is best between "COM2EXE" and "plain .EXE" (because it allows to imitate COM2EXE behavior, but it also allows define header in more flexible way). AS> So either there is a way for a device driver to safely go beyond its AS> original size, or perhaps I could try: AS> NASM => APACK => COM2EXE. No! Packer should come _after_ COM2EXE! AS> Eric, it wasn't clear for me what is the DISPORG.EXE thing that you AS> mentioned. As I understand, DISPORG.EXE is unUPXed executable, and Eric shows, that without bug in UPXed header, DISPLAY may be loaded into UMB. (Issue is only that DISPORG.EXE is 62k in size). AS> If it is just the same DISPLAY.EXE where you just modified AS> the EXE header, I can make just a temporary tool to patch it. AS> Best could be that I contact the UPX guys for it, but it may in turn AS> it could be that the decompressing algorythm may well NEED those 12X+ AS> KB to run. No! As I already show (please, see attentive my previous letters), identical executable (with only different initial values for CS:IP and SS:SP) does NOT requires so many memory. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] optimizing upx
Hi! 21-Авг-2006 18:22 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> --- EA> When requested dynamic memory is enough to fit unpacker, then EA> result is better. Unfortunately, anyway not ideal (required 16 bytes more, EA> than original). EA> --- EA> a typical arkady comment ;-) EA> 16 bytes... :-P Yes, not much difference. But this indicates bug in UPX, when it incorrectly calculates memory size (I suggest, so called "off +-1" bug, which usually appear as wrong bounds for loop variable). - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Compatibility EMM386/HIMEM 2.25 New Release
Yes, thank you very much! FreeDOS has a great himem and emm386! bye flo On Sun, 20 Aug 2006 19:05:12 +0200, Jim Hall <[EMAIL PROTECTED]> wrote: > Micheal, if you're ever in Minneapolis, I will definitely buy you a > beer. It's been great having you on the list. I love reading your > emails with the biting humor. It's great! You keep things from getting > dull. > > Seriously, you're a great developer, and we will miss you. You've > contributed a lot to FreeDOS. > > -jh > > > > Blair Campbell wrote: >> It's sad to see you leaving Michael, but thanks for all the wonderful >> work, and the humour along the way. The next maintainer has big shoes >> to fill :-). >> >> On 8/19/06, Michael Devore <[EMAIL PROTECTED]> wrote: >> > > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Hopefully last testing distribution
Hi, 2006/8/21, Arkady V.Belousov <[EMAIL PROTECTED]>: > Hi! > > 21--2006 17:22 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to > freedos-devel@lists.sourceforge.net: > > >> AFAIR, device driver not need to "expand" memory block - it already own > >> all free memory... As for .EXE, then its header already says to executable > >> loader, how much of memory it required, so not need to expand anything. > AS> Well, I was told (and I agree) that it is NOT safe to extend yourself > AS> beyond the memory that you initially own as a device driver. After > > Aitor, let me repeat again: not need to "extend" anything. MZ header Yes, now I understood your point. > >> 21--2006 03:41 [EMAIL PROTECTED] (Eric Auer) wrote to Aitor > >> Santamarзяa: > >> Wow! UPXed executable requires 128336 bytes to load! This explains, why > >> DISPLAY resist to load high... Interesting, where is bug/issue? When I > AS> Yeah, I supposed at Eric's analysis. > > Sorry, Aitor, above was only mine analysis. But results of Eric's > analysis is equal to mine. Yeah, I meant Eric's yesterday messages. > AS> However, will be a SYS in a near future. > > Why not combo, as EMM386? Yes, that will be the final option. > AS> Well, I don't have your nice ASCII quoting blackboard :) , > > ? __O\_/_\_/O__ This one :) _ O/~\ /~\O > AS> but here you have my make: > AS> === > AS> nasm display.asm -o display.com -i.\egavga\ > AS> com2exe display.com display.exe > AS> upx display.exe --8086 > AS> === > > Definitely not the best usage of COM2EXE. Reread help screen about > assumed memory usage. I mean, that in given case, when you not need > additional extra memory (except space for stack), you may use something like > > com2exe -s128 display.com display.exe > > (where 128 is space for stack), and you decrease required for load memory > from 64k to smaller value. Ok, I'll do. I think I recovered COM2EXE from CTMOUSE, any official site/pack for it? (with docs, or just the help screen). Aitor - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Hopefully last testing distribution
> ML> # FreeDOS is a trademark of Jim Hall MCMXCIV-MMIV I believe this should be: > ML> # FreeDOS is a trademark of Jim Hall MCMXCIV-MMVI two years have passed by... Alain - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 1.0 Testing under QEMU
Hi, The "out of memory" does not come from DISPLAY. MODE specific codepage 858 does not seem to be in the CPX/CPI file. But it is pretty weird that you get the MODE messages in that order, seems as is SELECT precedes PREPARE (!) Aitor 2006/8/21, Andreas Bollhalder <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello all > > I have tested the newest "fdbasecd.iso" (by 20060820) under QEMU. Maybe > my information here doubles some already mentioned points. > > == > I did a fresh install in "German" and "Español" with all options left to > default. > > When starting the installed FreeDOS system with the menu option > > 1 - Load FreeDOS with EMM386, no EMS (most UMBs), max RAM free > > or > > 2 - Load FreeDOS with EMM386+EMS and SHARE > > i get the following in the startup: > > ... > Display ver. 0.13b > Buffers allocated: 000 in TPA, 001 in XMS > Out of memory! > MODE select codepage 858 function failed > MODE: Specified codepage was not found in file > ... > > Using the menu option > > 3 - Load FreeDOS including HIMEM XMS-memory driver > > all works right. > > == > The "help" command freezes QEMU when using another language then > english. It is independend of the drivers loaded. > > C:\> help > > After that, I exchanged the files "C:\KERNEL.SYS", "C:\COMMAND.COM" and > "C:\FDOS\BIN\COMMAND.COM" with the english version. Changed in > "C:\FDCONFIG.SYS" the second line to "!SET lang=EN". The "help" command > now succeeds. > > Any hints for further testing ? > > Andreas > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFE6dsykyKr2gmercERAowAAKCo52ETHVOm8T7efXamZbnCzTk0ewCffybO > IFF2GrAeF3qiMxzkje1dKsc= > =m+qE > -END PGP SIGNATURE- > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Hopefully last testing distribution
Hi! 21--2006 17:22 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to freedos-devel@lists.sourceforge.net: >> AFAIR, device driver not need to "expand" memory block - it already own >> all free memory... As for .EXE, then its header already says to executable >> loader, how much of memory it required, so not need to expand anything. AS> Well, I was told (and I agree) that it is NOT safe to extend yourself AS> beyond the memory that you initially own as a device driver. After Aitor, let me repeat again: not need to "extend" anything. MZ header (for plain executable and for driver in .exe) already says for kernel, which minimum memory is required. If you eliminate some garbage from executable image and wish to keep total required memory, just increase MIN= filed in header (in case of COM2EXE, use -s option; for plain .exe-s, move DB's from initialized segments to uninitialized one - linker eliminates uninitialized areas from executable and increases MIN= for you). AS> all, DOS should have placed you in a hole big enough for it, but not Of course. Proper values in header will guarantee this. AS> guaranteed that I can go beyond. It _guaranteed_ if you properly set value for MIN= filed in header (through -s option for COM2EXE or explicitly defining all uninitialized variables in uninitialized segment for plain .EXE). AS> I could be wrong, of course (I wish I was). Sorry, you wrong. :) >> AS> Hence I have to book a lot of room with 0's >> AS> and then UPX it (code is around 2Kb, the rest to 11KB (using XMS) is >> AS> just that bunch of 0's, which is UPX-ed and compressed to less than >> AS> 4KB. >> But why at all store all zeros in executable? Why not clear memory >> after loading (if you need zeros)? Just ensure, that after program loading >> there is enough memory for this "bunch of 0's" - for this, ensure, that EXE >> header field "min memory" contains required value. AS> I do not need 0's. I just place 0's as they are better compresible AS> (UPX-able) in my original file. Nothing is "better compressible", than void! :) AS> The problem is that the program (in the future read: driver) resident AS> size is NOT known at compile time, because it depends from the AS> parameters specified by user in commandline (basically how many 9.5KB AS> buffers). AS> So the program is just the resident code plus a large amount of 0's AS> (имnit code) to be used as heap. Aitor, you wrongly mix two issues: storing or not storing zeros in executable doesn't solves issue with variable dynamic memory. As I understand, currently you just (pre)allocate maximum possible memory, and later just remain as resident only part of it. But again: this NOT relates to storing or not zeros in executable. Pre-allocate memory you may by explicitly filling executable by some garbage (by defining variables in initialized segment) OR by reserving space in MIN= field of header (by -s option, when you convert .COM by COM2EXE, or by moving definition to uninitialized segment for .EXE). Let me show examples. First source is .COM, converted to .EXE, in your style (with explicitly initialized garbage), second source is converted .COM without this garbage in executable, third source is plain executable: __O\_/_\_/O__ ; tasm/m testc1.asm ; tlink/t testc1.obj ; com2exe -s256 testc1.com testc1.exe .model tiny .code .startup .exit 0 .data font1 db 31*1024 dup (0) font2 db 31*1024 dup (0) end _ O/~\ /~\O __O\_/_\_/O__ ; tasm/m testc2.asm ; tlink/t testc2.obj ; com2exe -s63744 testc2.com testc2.exe ; (63744=62*1024+256) .model tiny .code .startup .exit 0 .data? font1 db 31*1024 dup (?) font2 db 31*1024 dup (?) end _ O/~\ /~\O __O\_/_\_/O__ ; tasm/m teste.asm ; tlink teste.obj .model small .code start: .exit 0 .data? font1 db 31*1024 dup (?) font2 db 31*1024 dup (?) .stack 256 end start _ O/~\ /~\O > >dir *.exe TESTC1 EXE63 526 TESTC2 EXE37 TESTEEXE 517 (TESTE.EXE uses 517 bytes because dumb TLINK always generates 512 bytes for header, even though it really smaller than 32 bytes). See the difference? Now, let study headers: __O\_/_\_/O__ Pages to load/last page size: 007D/0026h (125 pages/38 bytes) Relocation table offset/size: 001C/h (28 bytes/0 dwords) Header size: 0002h (2 para) Min/max memory to allocate: 0010/0010h (16/16 para) CS:IP: FFF0:0100h
Re: [Freedos-devel] upx explanation
Hi! 21-Авг-2006 18:33 Arkady V.Belousov wrote to freedos-devel@lists.sourceforge.net: AVB> - Min/max memory to allocate: 0009/h (9/65535 para) AVB> + Min/max memory to allocate: 0430/h (1072/65535 para) >>- Required memory to load: 41B0h (16816 bytes) >>+ Required memory to load: 4540h (17728 bytes) AVB> The more so, even for plain .EXE UPX requires more memory, than originally AVB> (17728 bytes instead 16816 bytes)! Sorry, second statement is not completely correct. If we increase required dynamic memory (for example, by using ".stack 12800" instead ".stack 128"), then result is not so worser: - Min/max memory to allocate: 0321/h (801/65535 para) + Min/max memory to allocate: 0710/h (1808/65535 para) - Required memory to load: 7330h (29488 bytes) + Required memory to load: 7340h (29504 bytes) This is because, there should be space for unpacker code itself, and in original example there is not enough space for it (9 para of dynamic memory). When requested dynamic memory is enough to fit unpacker, then result is better. Unfortunately, anyway not ideal (required 16 bytes more, than original). - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] 1.0 Testing under QEMU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all I have tested the newest "fdbasecd.iso" (by 20060820) under QEMU. Maybe my information here doubles some already mentioned points. == I did a fresh install in "German" and "Español" with all options left to default. When starting the installed FreeDOS system with the menu option 1 - Load FreeDOS with EMM386, no EMS (most UMBs), max RAM free or 2 - Load FreeDOS with EMM386+EMS and SHARE i get the following in the startup: ... Display ver. 0.13b Buffers allocated: 000 in TPA, 001 in XMS Out of memory! MODE select codepage 858 function failed MODE: Specified codepage was not found in file ... Using the menu option 3 - Load FreeDOS including HIMEM XMS-memory driver all works right. == The "help" command freezes QEMU when using another language then english. It is independend of the drivers loaded. C:\> help After that, I exchanged the files "C:\KERNEL.SYS", "C:\COMMAND.COM" and "C:\FDOS\BIN\COMMAND.COM" with the english version. Changed in "C:\FDCONFIG.SYS" the second line to "!SET lang=EN". The "help" command now succeeds. Any hints for further testing ? Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE6dsykyKr2gmercERAowAAKCo52ETHVOm8T7efXamZbnCzTk0ewCffybO IFF2GrAeF3qiMxzkje1dKsc= =m+qE -END PGP SIGNATURE- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] display exe versus upx versus loading high
Hi, 2006/8/21, Arkady V.Belousov <[EMAIL PROTECTED]>: > AS> actually supposed I was relying on caller's stack (I am not doing many > AS> weird things, not using C or the like, that can abuse the stack more > AS> than I do in assembler. > > There is no such thing as "caller stack" when we discuss transient > portion (which gets control, when program starts). True, sorry. I was mislead with the resident portion. > >> You either have to use another compressor, design your > >> program as a proper EXE with own stack, or ask some UPX > >> expert to fix the sub-optimal workings of UPX for your > >> case. At least you can be sure that this is NOT a FreeDOS > >> kernel problem. > AS> Well, I have an option which is better (easier) than the other three > AS> that you gave me: wait until DISPLAY becomes DISPLAY.SYS. As I said, > > Not need to convert exe/sys to plain sys, especially because combo may > give additional features (like information about status) without additional > executables. I was talking of converting COM to SYS. I may try to make it an EXE (in the future a COMBO), but it seems that I won't be saved from UPX greediness. So either there is a way for a device driver to safely go beyond its original size, or perhaps I could try: NASM => APACK => COM2EXE. Eric, it wasn't clear for me what is the DISPORG.EXE thing that you mentioned. If it is just the same DISPLAY.EXE where you just modified the EXE header, I can make just a temporary tool to patch it. Best could be that I contact the UPX guys for it, but it may in turn it could be that the decompressing algorythm may well NEED those 12X+ KB to run. Aitor - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Hopefully last testing distribution
Hi,
2006/8/21, Arkady V.Belousov <[EMAIL PROTECTED]>:
Hi!
21--2006 02:30 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to
freedos-devel@lists.sourceforge.net:
>> - DISPLAY somehow manages to resist LOADHIGH, Aitor! Maybe it
>> just tries to be too clever...
AS> Not at all. I remind you (discussed long ago) that it happens because
AS> of UPX. The creation of DISPLAY is:
AS> NASM => COM2EXE => UPX
AS> I must use UPX, because (as I asked here long ago) I cannot, as a
AS> device driver (and will not do for EXE, as I will explain for KEYB)
AS> EXPAND my memory block.
AFAIR, device driver not need to "expand" memory block - it already own
all free memory... As for .EXE, then its header already says to executable
loader, how much of memory it required, so not need to expand anything.
Well, I was told (and I agree) that it is NOT safe to extend yourself
beyond the memory that you initially own as a device driver. After
all, DOS should have placed you in a hole big enough for it, but not
guaranteed that I can go beyond. I could be wrong, of course (I wish I
was).
AS> Hence I have to book a lot of room with 0's
AS> and then UPX it (code is around 2Kb, the rest to 11KB (using XMS) is
AS> just that bunch of 0's, which is UPX-ed and compressed to less than
AS> 4KB.
But why at all store all zeros in executable? Why not clear memory
after loading (if you need zeros)? Just ensure, that after program loading
there is enough memory for this "bunch of 0's" - for this, ensure, that EXE
header field "min memory" contains required value.
I do not need 0's. I just place 0's as they are better compresible
(UPX-able) in my original file.
The problem is that the program (in the future read: driver) resident
size is NOT known at compile time, because it depends from the
parameters specified by user in commandline (basically how many 9.5KB
buffers).
So the program is just the resident code plus a large amount of 0's
(ìnit code) to be used as heap.
21--2006 03:41 [EMAIL PROTECTED] (Eric Auer) wrote to Aitor
Santamarэa:
Wow! UPXed executable requires 128336 bytes to load! This explains, why
DISPLAY resist to load high... Interesting, where is bug/issue? When I
Yeah, I supposed at Eric's analysis.
repack DISPLAY by UPX ("upx --8086 --brute"), it again begins require 128k
to load - looks like bad algorithm in UPX. After packing executable by
aPACK ("apack -x"), it now requires only original 64k of memory to load.
Pity, that aPACK doesn't support exe/sys.
Well, DISPLAY is just a transformed COM, so I could use it. However,
will be a SYS in a near future.
EA> Because your program is an EXE, the DOS kernel can figure
EA> out how much it needs to be run. Either your MS DOS has
EA> 128k consecutive UMB space when your run DISPLAY or your
EA> MS DOS is violating its own specs... However, UPX is quite
EA> pessimistic about needed space. If you would NOT UPX your
EA> program, you would only need roughly 64k to load DISPLAY!
Precisely. The more so, if not preserve all zeros in executable, then
it will be reduced even more, than after packing.
Yes, but as I explained in my other message, I don't want to expand
own memory block, as I won't be able to do it as a device driver
(unless unfortunately I am not wrong).
EA> There are various possible solutions. If you UPX a DISPLAY.com
EA> file,
No! NEVER-NEVER-NEVER make resident programs as .COM files (I mean,
resident should be compiled as .EXE or converted from .COM to .EXE), because
.COM files don't have header, which notifies system, how much precisely
programs it need! Without this, .COM program may be loaded into too small
UMB block, and, if program doesn't check this, it will overwrite MCB chain
headers!
The thing is that I don't need MORE memory than the original one that
I have (in fact, once gone resident I just need something like 11KB,
if you have XMS).
EA> If you make DISPLAY a true EXE
Converted (from .COM to .EXE) executable _is_ "true EXE". Of course,
when you convert, you shouldn't forget to specify, how much memory will be
required after program loading. With my COM2EXE, use option -s.
Interesting... I'll see available options.
EA> which knows well about how
EA> much heap it needs and preferrably also has a real stack
EA> (not "initial SS:SP = PSP:fffe"),
For .COM and .COM with .EXE header, this _is_ real stack. But, with my
COM2EXE, if you specify (by -s option), that program requires less than 64k
of memory after load, stack (SP) will be consequently adjusted.
EA> You either have to use another compressor, design your
EA> program as a proper EXE with own stack, or ask some UPX
EA> expert to fix the sub-optimal workings of UPX for your
EA> case.
Second advice is ir-relevant, third (I think) is best (if UPX will be
really fixed). And you miss there advise with eliminating zeros from
executables - this allows to not use packer at all (because I doubt that
compressing 2k to, say, 1.4k gives much advantage).
I wouldn't
Re: [Freedos-devel] upx explanation
Hi! 21-Авг-2006 14:34 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> i do know how exe files work. what i am trying to explain is EA> that the upx decompressor does NOT set values for ss:sp. it EA> ONLY sets a value for ss. So what? May be, this is way to preserve original SP value without modifying stub? Eric, don't cycle around this value, it irrelevant (unless we view stub sources and prove, that this value is buggy). EA> and because com2exe programs have a sp of -2, ...as it should be for .COM programs. EA> the ss:sp is cs_of_decompressor:-2 during EA> decompression. which is bad. First, why you think about "cs_of_decompressor" (even if in some cases SS may be equal to CS field)? Second, why this is bad (whereas there is only one requirement: stack pointer should point not over code/date, but only over non-used space in image or to dynamic memory. EA> AFTER decompression, upx sets EA> ss:sp to cs_of_display:-2, which is okay. *IF* UPX sets SS to CS_OF_DISPLAY, then this is bug. It should set SS to PSP_SEGMENT+SS_FIELD_OF_HEADER. SS=CS only for plain .COM and .EXE, converted from .COM. EA> the problem is that EA> cs_of_decompressor is 62 kilobytes AFTER cs_of_display. No. Problem is, that UPXed header requires 128k memory for loading (image + dynamic memory), whereas original program requires only 62k. So, this is bug in UPX (which writes in header too big value for MIN= field) or this is too greedy unpacking algorithm. All of this absolutely irrelevent with handling CS:IP and SS:SP values. EA> if upx would set BOTH ss AND sp, there would not be a problem. Irrelevent. EA> stack could be at cs_of_decompressor:1000 during decompression EA> and at cs_of_display:-2 after decompression. Irrelevant. Unpacker should set SS:SP to original values from header (ie., PSP_SEG+SS_FIELD:SP_FIELD). Which values it uses for itself in packed executable header absolutely unimportant. And if compressor (noticeably) increases MIN= field value only to preserve some specific value for SS:SP in header, then this is bug. Well, let make another tests. Below two sources (first for .COM file, converted to .EXE, and second for .EXE file): __O\_/_\_/O__ ; tasm/m testc.asm ; tlink/t testc.obj ; com2exe -s128 testc.com testc.exe .model tiny .code .startup .exit 0 db 16*1024 dup (0) end _ O/~\ /~\O __O\_/_\_/O__ ; tasm/m teste.asm ; tlink teste.obj .model small .code .startup .exit 0 db 16*1024 dup (0) .stack 128 end _ O/~\ /~\O As you see, programs (almost) identical, execpt initial values for CS:IP and SS:SP. Now, differences between first unpacked/packed .exe-s and second unpacked/packed .exe-s: __O\_/_\_/O__ -Pages to load/last page size: 0021/0025h (33 pages/37 bytes) +Pages to load/last page size: 0001/0118h (1 pages/280 bytes) -Relocation table offset/size: 001C/h (28 bytes/0 dwords) +Relocation table offset/size: 001C/0001h (28 bytes/1 dwords) Header size: 0002h (2 para) - Min/max memory to allocate: 0008/0008h (8/8 para) + Min/max memory to allocate: 080B/080Bh (2059/2059 para) - CS:IP: FFF0:0100h + CS:IP: :h - SS:SP: FFF0:418Eh + SS:SP: 0402:418Eh Checksum: h Overlay #: h (0) - File size: 4025h (16421 bytes) + File size: 0118h (280 bytes) Header size: 0020h (32 bytes) - Program image size: 4005h (16389 bytes) + Program image size: 00F8h (248 bytes) >- Required memory to load: 4190h (16784 bytes) >+ Required memory to load: 82B0h (33456 bytes) _ O/~\ /~\O __O\_/_\_/O__ -Pages to load/last page size: 0022/001Ch (34 pages/28 bytes) +Pages to load/last page size: 0001/015Fh (1 pages/351 bytes) -Relocation table offset/size: 003E/0001h (62 bytes/1 dwords) +Relocation table offset/size: 001C/0001h (28 bytes/1 dwords) - Header size: 0020h (32 para) + Header size: 0002h (2 para) - Min/max memory to allocate: 0009/h (9/65535 para) + Min/max memory to allocate: 0430/h (1072/65535 para) CS:IP: :h - SS:SP: 0402:0080h + SS:SP: 0424:0200h Checksum: h
Re: [Freedos-devel] display exe versus upx versus loading high
Hi! 21-Авг-2006 03:57 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to "Eric Auer" <[EMAIL PROTECTED]>: AS> I think this was the problem when it was a COM, Bernd, can you AS> remember the details? Sure. Read my previous letter - because resident programs NEVER should by in .COM format (without header, which specifies executable requirements for dynamic memory). >> If you make DISPLAY a true EXE which knows well about how >> much heap it needs and preferrably also has a real stack AS> Arkady may help with the settings of the EXE header for COM2EXE. I All simple. If your program doesn't requires additional memory (in compare with data, already present in executable), just use something like "-s32" option (this dynamic memory+stack, and 32 bytes of stack should be minimum specified). If your program requires additional memory after start (for example, if you eliminate from executable 62000 bytes of zeros, but require 62000 bytes of memory for these zeros after start), specify something like "-s62032" option (62000 bytes of dynamic memory + 32 bytes for stack). Of course, space for stack may (and should be?) more, than 32 bytes (even if your code is not too recursive). This is because some BIOS calls advertised as required at least 128-512 bytes of stack space. AS> actually supposed I was relying on caller's stack (I am not doing many AS> weird things, not using C or the like, that can abuse the stack more AS> than I do in assembler. There is no such thing as "caller stack" when we discuss transient portion (which gets control, when program starts). >> You either have to use another compressor, design your >> program as a proper EXE with own stack, or ask some UPX >> expert to fix the sub-optimal workings of UPX for your >> case. At least you can be sure that this is NOT a FreeDOS >> kernel problem. AS> Well, I have an option which is better (easier) than the other three AS> that you gave me: wait until DISPLAY becomes DISPLAY.SYS. As I said, Not need to convert exe/sys to plain sys, especially because combo may give additional features (like information about status) without additional executables. AS> I've willing to finish with that the soonest, and I really wanted 0.13 AS> be the last one before 1.0 (but won't be, as 0.13. was a "quick" AS> release for FD 1.0). AS> I would nonetheless inform UPX guys about this... - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Hopefully last testing distribution
Hi!
21--2006 02:30 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to
freedos-devel@lists.sourceforge.net:
>> - DISPLAY somehow manages to resist LOADHIGH, Aitor! Maybe it
>> just tries to be too clever...
AS> Not at all. I remind you (discussed long ago) that it happens because
AS> of UPX. The creation of DISPLAY is:
AS> NASM => COM2EXE => UPX
AS> I must use UPX, because (as I asked here long ago) I cannot, as a
AS> device driver (and will not do for EXE, as I will explain for KEYB)
AS> EXPAND my memory block.
AFAIR, device driver not need to "expand" memory block - it already own
all free memory... As for .EXE, then its header already says to executable
loader, how much of memory it required, so not need to expand anything.
AS> Hence I have to book a lot of room with 0's
AS> and then UPX it (code is around 2Kb, the rest to 11KB (using XMS) is
AS> just that bunch of 0's, which is UPX-ed and compressed to less than
AS> 4KB.
But why at all store all zeros in executable? Why not clear memory
after loading (if you need zeros)? Just ensure, that after program loading
there is enough memory for this "bunch of 0's" - for this, ensure, that EXE
header field "min memory" contains required value.
AS> This happens to work perfectly well for MS-DOS (where I can load high
AS> without problem), but I guess that FreeDOS kernel does not like very
AS> much (I suppose) that the program is expanded after being loaded. I
Oops. More details, please.
AS> didn't have time to digg into kernel sources yet to see where the
AS> problem is, but I was also hoping not to release any more .EXEs.
?
AS> However, the bug remains (in my opinion) in the kernel, interesting to
AS> be looked at.
Again, mode details, please!
21--2006 03:41 [EMAIL PROTECTED] (Eric Auer) wrote to Aitor
Santamarэa:
EA> Hi Aitor, your problem is not in FreeDOS, it is in
EA> how your program is organized and in how UPX does
EA> not handle that well...
I suggest this too.
>>> - DISPLAY somehow manages to resist LOADHIGH, Aitor!
>> Not at all. I remind you (discussed long ago) that it happens
>> because of UPX. The creation of DISPLAY is: NASM => COM2EXE => UPX
>> I must use UPX, because (as I asked here long ago) I cannot, as a
>> device driver (and will not do for EXE, as I will explain for KEYB)
>> EXPAND my memory block. Hence I have to book a lot of room with 0's
EA> UPX reports that the EXE would normally be 62 kilobytes...
EA> Checking the header of the de-UPXed version of DISPLAY...
Interesting... Let me check myself. Bellow difference between
distributed original executable and de-UPXed one:
__O\_/_\_/O__
-Pages to load/last page size: 0008/0043h (8 pages/67 bytes)
+Pages to load/last page size: 007B/0047h (123 pages/71 bytes)
-Relocation table offset/size: 001C/0001h (28 bytes/1 dwords)
+Relocation table offset/size: 0020/h (32 bytes/0 dwords)
Header size: 0002h (2 para)
- Min/max memory to allocate: 1E62/h (7778/65535 para)
+ Min/max memory to allocate: 00AD/h (173/65535 para)
- CS:IP: :h
+ CS:IP: FFF0:0100h
- SS:SP: 0F44:FFFEh
+ SS:SP: FFF0:FFFEh
Checksum: h
Overlay #: h (0)
- File size: 0E43h (3651 bytes)
+ File size: F447h (62535 bytes)
Header size: 0020h (32 bytes)
- Program image size: 0E23h (3619 bytes)
+ Program image size: F427h (62503 bytes)
- Required memory to load: 0001F550h (128336 bytes)
+ Required memory to load: 0001h (65536 bytes)
_
O/~\ /~\O
Wow! UPXed executable requires 128336 bytes to load! This explains, why
DISPLAY resist to load high... Interesting, where is bug/issue? When I
repack DISPLAY by UPX ("upx --8086 --brute"), it again begins require 128k
to load - looks like bad algorithm in UPX. After packing executable by
aPACK ("apack -x"), it now requires only original 64k of memory to load.
Pity, that aPACK doesn't support exe/sys.
EA> is a bit tricky but the main point here is: Your EXE
EA> file tells that it needs to be loaded into a memory
EA> block of at least 128611 (decimal) bytes while, when
EA> you de-UPX it, it tells that it would need only
EA> 65815 (decimal) bytes. Still much for something which
EA> should be loaded high. I think the difference is
Precisely!
EA> caused by your "my stack is 64k and the binary will
EA> decompress to 61.5k" which makes UPX go for "this
EA> file will need 125.5k (4k loaded plus 121k heap) to
EA> be run" for some reason.
I think, this is bug in UPX or this is too greedy algorithm in UPX.
>> This happens to work perfectly well for MS-DOS (where I can load high
>> without
