Can 64-bit programs run on OS/2?

[Dariusz Piatkowski]

Why? Which programs? Which 64 bit program will work in the given 4GB address space? Moreover which 64 bit program is of any use in our restricted address space?...

I think Andi is right on the money here.

If saying '64-bit' is sexy...well, that's nice, but we all live with the old "you can look, but you can't touch" law of the OS/2 land, don't we??? LOL

So instead of dreaming of this pie-in-the-sky thing, I would rather spend any possible efforts on fixing the weak points we have today: geez, has anyone ran into the shared memory mess recently? C'mon, there's got to be a better way to handle this...can't we implement some kind of "OS2 shared memory garbage collector"

Look, those piece-improvements will net us a WHOLE lot more value then trying to get a 64-bit foundation in place....and for what? Like Andi's question goes: what are the apps we need 64-bit computing for???

Guys seriously...I moved to a giant 1G JFS cache a little over a month ago...I have been logging the results of various configuration changes as I try them out, all because my impression is that we have very little knowledge left on our platform today to make the most of what we currently have, let alone developing new stuff.

Let's get some decent airtime from QSINIT's upper memory provisioning capability...yeah, I can think of a few apps right now where that extra memory would come in handy: PMVIew manipulating a 1200 dpi TIFF scan...oh yeah, that's hardly something that's going to live with a 1G JFS cache under the same "roof"...!

[Andreas Schnellbacher]

can't we implement some kind of "OS2 shared memory garbage collector"

Who is "we" ;-)? Rewriting the memory management means to fight with Assembler and to deal with the closed-source kernel code. Wouldn't it be easier to start with a Linux system and add the OS/2 specials to it? There were ideas 10 ... 20 years ago.

[Dave Yeo]

Simplest for shared memory is preloading DLL's and keeping them loaded. This avoids the memory fragmentation that will happen over time to a large extent. Still have the problem that shared memory, especially in the low arena, is a limited resource on OS/2. Being shared memory also means you can't easily extend it through tricks with PAE and such.
Perhaps it is possible to use more private memory. Back in the SeaMonkey 1.x days before we learned the tricks of using high memory, I used to build SeaMonkey with --disable-shared --enable-static. You'd get a huge seamonkey.exe and only a few DLL's such as the NSPR4 and NSS ones. This seemed to help a lot in not running out of memory, though at the time I didn't know how to measure it.
I don't really understand how OS/2 uses private memory and whether it can allocate multiple chunks in the same address area. In theory it could, the i386 does support about 2TB's of virtual memory and we can load multiple DOS sessions, up to 99, all using the same address range and using DPMS, each using 2 GB's of ram. Of course if you try that, you run into internal limits like the swap file using a signed int so limited to 2 GB's. Probably lots of other places in the kernel similar. The original kernel writers probably never imagined running OS/2 on systems with GB's of ram. They were lucky to have over 8-16MB's of ram.