-=> Quoting hugo landsman to Phil Crown <=- 

 hl> hi Phil,
 
 PC> I ported kpop.c to 32 bits, which was basically just removing the
 PC> __loadds and far identifiers.

 hl> And that was a bit too simple:-)  You have to ensure that the data you
 hl> exchange with 16-bit functions doesn't change size.  Ie. where the
 hl> 16-bit code says 'unsigned', change to USHORT and the like.

Yes, thanks, I believe I'm aware of this...

..well, I just checked, it seems I missed this.  Good point! :-)

 PC> My biggest worry is that the buffers passed to DosMonReg cannot
 PC> cross a 64k boundary.  I'm hoping there is a compiler switch I can
 PC> use to ensure this does not happen, but it will be my luck that it
 PC> is not that easy...

 hl> No, there isn't a switch, but there is _tmalloc(), which you have to
 hl> use wherever you exchange data pointers with the 16-bit functions.  It
 hl> allocates the tiled memory they need (or else the program willl
 hl> coredump seamingly at readom).  See the now functioning code I
 hl> e-mailed you yesterday;-) 
 hl> groetjes,
 hl> hugo

I'll be looking for it.  Where did you mail it to (Internet or Fido
email)?

Another example using DosMon (snippet from XFree86/2) uses _tmalloc(),
but it had been commented out and was not being used.  I guess it was
compiled for 32-bits.

I am not using any *malloc'ing at all, but it is working.  Guess I'm
lucky that it isn't crossing any 64k boundaries at the moment.

I've managed to piece together a working copy from various places.  I'm
now mucking with calling DosStartSession from a detached program to
start a PM server program to paste text from the OS/2 clipboard.

Phil - Fido:  1:124/8014.0 | Internet:  phil.crown{at}bluecafe.com


--- Blue Wave/OS2 v2.30