Re: [Freedos-user] counterproductive UPX usage for loadhigh display /maybe other drivers also/?

[Jerome Shidel]

> On Jan 3, 2018, at 3:29 AM, Rugxulo  wrote:
>> […]
>> wrong. this behaviour should simply be fixed, as the fix is trivial:
>> 
>>   get a recent UPX.
>>   decompress.
>>   recompress.
>>   wait for FreeDOS 2.0 to have this fix published.
> 
> I have followed Tom's advice and updated the package:

Actually, after seeing Tom’s advice, I was thinking it may be a good idea to 
work through all the packages that have
UPX compressed binaries. That way they all are compressed using the latest 
version of UPX.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] counterproductive UPX usage for loadhigh display /maybe other drivers also/?

[Rugxulo]

Hi,

On Tue, Jan 2, 2018 at 9:32 AM, Tom Ehlert  wrote:
>
>> Hi, I just tried to 'lh display', but it always ends in conventional
>> memory (code, codepages are perhaps in XMS):
>
> fortunately, after recompressing with the current UPX, the minimum
> required load size is only minimally increased, and still load high as
> the uncompressed display.exe
>
>> What is essential - if so, then this behavior should be IMO mentioned in
>> the display documentation (or elsewhere).
>
> wrong. this behaviour should simply be fixed, as the fix is trivial:
>
>get a recent UPX.
>decompress.
>recompress.
>wait for FreeDOS 2.0 to have this fix published.

I have followed Tom's advice and updated the package:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/display.html

Please take a look, and tell us if this is okay.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] counterproductive UPX usage for loadhigh display /maybe other drivers also/?

[Tom Ehlert]

Hi,

> Hi, I just tried to 'lh display', but it always ends in conventional
> memory (code, codepages are perhaps in XMS):
...

> I myself explain this that the UPX-ed program is probably going to UMB,
> but after its decompression, its resident part will no longer fit there
> for some reason and is placed into conventional memory.

this is right. the .EXE header utility EXEHDR (there are many others)
reports (beyond other stuff) for the UPX'ed file

e:\>exemod y:\temp\BIN\DISPLAY.EXE

   Microsoft (R) EXE File Header Utility  Version 4.02
   y:\temp\BIN\DISPLAY.EXE(hex)   (dec)

   .EXE size (bytes)E433651
>>>Minimum load size (bytes)  1F443  128067
   Minimum allocation (para)   1E627778

after decompressing, minimum load size is much smaller

  e:>upx -d  y:\temp\BIN\DISPLAY.EXE
   Ultimate Packer for eXecutables
  Copyright (C) 1996 - 2017
  UPX 3.93w   Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 29th 
2017

  File size Ratio  Format  Name
    --   ---   ---
  62535 <-  36515.84% dos/exe DISPLAY.EXE

  Unpacked 1 file.

  e:\ntsource\snapshot>exemod y:\temp\BIN\DISPLAY.EXE

  Microsoft (R) EXE File Header Utility  Version 4.02
  y:\temp\BIN\DISPLAY.EXE(hex)   (dec)

  .EXE size (bytes)   F447   62535
>>>   Minimum load size (bytes)   FEF7   65271
  Minimum allocation (para) AD 173



fortunately, after recompressing with the current UPX, the minimum
required load size is only minimally increased, and still load high as
the uncompressed display.exe

 e:\>upx  y:\temp\BIN\DISPLAY.EXE
   Ultimate Packer for eXecutables
  Copyright (C) 1996 - 2017
 UPX 3.93w   Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 
29th 2017

 File size Ratio  Format  Name
   --   ---   ---
 62535 ->  36435.83% dos/exe DISPLAY.EXE

 Packed 1 file.

 e:\>exemod y:\temp\BIN\DISPLAY.EXE

 Microsoft (R) EXE File Header Utility  Version 4.02
 y:\temp\BIN\DISPLAY.EXE(hex)   (dec)

 .EXE size (bytes)E3B3643
>>>  Minimum load size (bytes)   FEFB   65275
 Minimum allocation (para)F0E3854



> What is essential - if so, then this behavior should be IMO mentioned in
> the display documentation (or elsewhere).

wrong. this behaviour should simply be fixed, as the fix is trivial:

   get a recent UPX.
   decompress.
   recompress.
   wait for FreeDOS 2.0 to have this fix published.


some more remarks:

( I didn't look at the sources, so take this with a grain of salt)

12K resident is, even when loaded high, a significant number.
as the compressed .EXE size is just 3,5 K, the executable logic is
most likely ~5 KB size, and the other ~7 KB is buffer space to store font
information.

to move this font buffer to XMS memory shouldn't be a big deal, and
make up ~7 KB more UMB memory.

( in the good old times people would have killed for 7 KB memory :-)

as I have no interest in display.exe, I left this as an exercise to
the reader.


Tom


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] counterproductive UPX usage for loadhigh display /maybe other drivers also/?

[Franta Hanzlík]

Hi, I just tried to 'lh display', but it always ends in conventional
memory (code, codepages are perhaps in XMS):
C:\>mem /c
 
Modules using memory below 1 MB:
 
  NameTotal  Conventional   Upper Memory
          
  SYSTEM  21,056   (21K) 10,896   (11K) 10,160   (10K)
  EMS160(0K)160(0K)  0(0K)
  DISPLAY 12,048   (12K) 12,048   (12K)  0(0K)
  EMUFS  128(0K)  0(0K)128(0K)
  COMMAND  4,064(4K)  0(0K)  4,064(4K)
  Free   752,784  (735K)631,952  (617K)120,832  (118K)

C:\>dir z:\bin\DISPLAY.EXE
 Volume in drive Z is emu/drive_z
 
 Directory of Z:\BIN
 
DISPLAY  EXE 3,651  08-06-06  8:54p
(display.exe v0.13b)

Success comes after decompressing the display.exe utility - it then has
roughly 62.5 kB on disk, but it can be loaded into UMB without problems
(with 'lh display' command):

C:\>mem /c
 
Modules using memory below 1 MB:
 
  NameTotal  Conventional   Upper Memory
          
  SYSTEM  21,056   (21K) 10,896   (11K) 10,160   (10K)
  EMS160(0K)160(0K)  0(0K)
  EMUFS  128(0K)  0(0K)128(0K)
  COMMAND  4,064(4K)  0(0K)  4,064(4K)
  DISPLAY 12,048   (12K)  0(0K) 12,048   (12K)
  Free   752,816  (735K)644,032  (629K)108,784  (106K)

I myself explain this that the UPX-ed program is probably going to UMB,
but after its decompression, its resident part will no longer fit there
for some reason and is placed into conventional memory.
What is essential - if so, then this behavior should be IMO mentioned in
the display documentation (or elsewhere). I think most users will prefer
to lose a few kb of disk space in favor of more free conventional memory.

PS: I would like to wish the FreeDOS project, its development team and
all users for a healthy and successful new year 2018 (even years later,
 of course)!
-- 
Thanks, Franta Hanzlik

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user