>> PE> What I am wondering is whether

 >> PE> EVERY 32-bit address I can allocate can be converted

 >> PE> into a 16:16. If it



 >> Yes, you can convert any address from a 0:32 (actually, if

 >> you want to be pedantic, this should be called 16:32) to a

 >> 16:16 and vice versa.



 dn> Hmm, look again. You can't fit 48 bits into 32 no matter how big a hammer

 dn> you might use. :-)  When you use DosAllocMem(), you can specifically

 dn> request 'tiled' memory (memory which can be converted to 16:16) or not.



Ok, you're right. In the full 4 gigabyte address space, not all bytes area
addressable by a 16:16 pointer. However, OS/2 currently only allocates 512
meg to each process, so all bytes are addressable by both 16:16 and 0:32
addresses.



According to what I've read, all memory requests are forced to be tiled
under the current version of OS/2. Obviously this may change and if you
need compatability with 16:16 code you should expicitly request tiled
memory.



 dn> It is actually 0:32 since separate segments aren't used in flat model. If

 dn> the OS/2 kernel allowed modification of segment registers in 32-bit code

 dn> segments (and it does, but for ring 0 code only), then it might arguably

 dn> be called 16:32.



Each process has one segement. It's just 4 gig in size :-)



 >> These sorts of problems will keep occuring until IBM pulls

 >> their finger out and rewrites these routines as 32 bit code.



 dn> According to an IBM enginerr I exchanged some email with recently, IBM

 dn> already have 32-bit versions of their subsystems, but from what he said I

 dn> doubt that they'll ever be seen out in released code. The general

 dn> approach is that (1) IBM isn't committed to Vio applications, (2) that

 dn> IBM aren't guaranteeing forward compatibility with ports of OS/2 to other

 dn> architectures and (3) IBM doesn't want to 'waste' resources on bug fixes

 dn> and enhancements to an area of the operating system in which they are not

 dn> particularly interested.



I guess they've also got to be careful not to break the existing 16 bit
applications.



 dn> In other words, it's not broke and it doesn't need fixing, and especially

 dn> doesn't need enhancing.



 dn> Pity.  I quite like text mode apps myself, but I came to face the music

 dn> on hearing this.  I'll still continue to use (and even produce) text mode

 dn> apps in spite of it, but I've already shifted into GUI development.



The steep learning curve developing GUI applications is a pain. It's almost
enough to take the fun out of programming :-(



 >> And you thought that we'd left all this stuffing around

 >> behind us when we went OS/2 :-(



 dn> You'd rather use software interrupts and an API like Windows?  :-)



No, but I do have this soft spot for punched card output :-)



Paul



--- GoldED 2.40