Author Topic: app high-mem capability, how to tell if it's there?  (Read 1633 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1431
  • Karma: +28/-0
    • View Profile
app high-mem capability, how to tell if it's there?
« on: December 31, 2024, 09:27:43 pm »
...basically, when looking at either an EXE or a DLL, how can I tell whether the application was written/compiled with highmem support?

I am aware of 'highmem', and stuff like 'exehdr', but even in the case of 'exehdr' I do not see how to interpret the results (i.e. is there anything in the output I am missing that already shows me that "yup, highmem capable" flag?).

Yes, I agree that leaving things "as-is" (meaning: the way the software was supplied) is a good recommendation, but if changes were made (we've all marked DLLs to load-high I'm sure) how the heck do I figure out what the intended DEFAULT mode is???

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5365
  • Karma: +127/-1
    • View Profile
Re: app high-mem capability, how to tell if it's there?
« Reply #1 on: January 01, 2025, 12:09:51 am »
Pretty easy. Marking a random DLL to load high, exehdr outputs,
Code: [Select]
Operating System/2 Executable File Header Utility

Version 4.01.003 Dec 11 2003

Copyright (C) IBM Corporation 1988-2003

Copyright (C) Microsoft Corp. 1988-1992.

All rights reserved.

Library:                        Qt6Concu
Description:                    @#cmake build system:6.2.10#@##1## 29 Dec 2024 1
2:09:46     ARCAOS-44454C4::::0::@@Concurrent

Module type:                    Dynamic link library
                                Per-process initialization
                                Per-process termination
                                NO internal fixups in executable image
Number of memory pages:         00000003 (3)
Initial CS:EIP:                 object 1 offset 00000000
Initial SS:ESP:                 object 0 offset 00000000
Automatic data object:          2

 no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 00001320 00000001 00000002 EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00020000 00000740 00000003 00000001 READABLE, WRITEABLE, 32-bit


Exports:
...

Note that the default exehdr (4.01.001 doesn't display the HIMEM flag, I used the one from the toolkit (attached), not the one installed by RPM, likely the toolkit package.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1431
  • Karma: +28/-0
    • View Profile
Re: app high-mem capability, how to tell if it's there?
« Reply #2 on: January 01, 2025, 06:07:11 pm »
Hello Dave!

Happy 2025 to you...

Pretty easy. Marking a random DLL to load high, exehdr outputs,
Code: [Select]
...
Automatic data object:          2

 no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 00001320 00000001 00000002 EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00020000 00000740 00000003 00000001 READABLE, WRITEABLE, 32-bit

OK, cool...I am using the 4.01.003 version here already, and indeed that points to the 'flag' that shows me the current state/mark, thank you, great to know this b/c I've been relying on 'highmem -v' up to now.

Alright...so how about the way the EXE/DLL were compiled??? I thought that in order to enable highmem one had to run a special flag during either the compile or link stages??? Would that not be present somewhere?

That is really what I'm after here...b/c having flipped that highmem flag ON/OFF a number of times, how the heck do I know what the DEFAULT setting was?

I suppose that perhaps this question in a sense dovetails into the following:

1) when should something be marked as 'code' highmem enabled
2) when should something be marked as 'data' highmem enabled
3) when should something be marked as 'both' highmem enabled

For now I am under the impression that anything using 16bit stuff must NOT be highmem enabled, for any of the above settings.

So a more specific example: looking at our Lucide PDF viewer, I see the following for lucide1.dll

1) 'code' marked as highmem
Code: [Select]
no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

2) 'data marked as highmem
Code: [Select]
no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit, HIMEM
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

3) 'both' marked as highmem
Code: [Select]
no. virtual  virtual  map      map      flags
     address   size    index    size
0001 00010000 0005d0f0 00000001 0000005e EXECUTABLE, READABLE, 32-bit, HIMEM
0002 00070000 0001b6f0 0000005f 00000016 READABLE, WRITEABLE, 32-bit, HIMEM
0003 00000000 0000c680 00000075 0000000d READABLE, SHARED, RESOURCE,
                                         DISCARDABLE, 32-bit

So it is the different object #s that are impacted, this I can see, but just looking at the details and seeing "...32-bit...", is that sufficient enough for me to consider that highmem safe for any of those combinations?

I am using Lucide as an example b/c I've had a nagging issue with this thing freezing during PDF file opening...sort of a soft-lock...I can usually kill the process, but sometimes it's caused my WPS to shut-down...which is really weird. This typically happens when I'm opening a PDF on the NAS, and very rarely, if ever, when opening a local PDF.

Anyways, since the NAS path is complicated (NetDrive: the plugins, samba stuff, etc.) I am trying to work through that whole stream to confirm that all of it is correctly configured...yeah, kind of a needle in a haystack kind of a thing...LOL!

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5365
  • Karma: +127/-1
    • View Profile
Re: app high-mem capability, how to tell if it's there?
« Reply #3 on: January 01, 2025, 07:30:49 pm »
OK, as far as I understand it, there are 2 ways that high memory is used. Loading the DLL/EXE code and/or data segment into high memory when the object is loaded. Loading the code high is usually safe as long as no 16 bit code, data high varies. I remember with Mozilla experimenting, it was weird, one version would work fine with both loaded, another version would be crashy with the data loaded high. Sometimes you have to experiment, or just stick with loading code high.
The other way is when allocating memory, pass the flag OBJ_ANY to DosAllocMem() etc and memory will be allocated in the high arena if possible. With GCC, there's the -Zhigh-mem parameter that automates this as well as os2safe.h (now automatically included) which has workarounds for the 16 bit API functions.
For this, if you don't have access to the source, or at least the build flags in the case of GCC, I guess using something like Theseus to look at where the memory is allocated is about the only way to check.