🚀 go-pugleaf

In article <600@rodan.cs.utexas.edu> nickel@cs.utexas.edu (Jody P. Nickel) writes:
>This isn't pretty but... And I'm sure Microsoft won't condone it. The pointer
>returned will always be an XXXX:0000, where XXXX is the selector for the
>first 64K of the memory. 

You are pretty much assured that a GlobalAlloced memory block starts at
offset 0.  MS certainly can't change this without some form of 
backwards compatbility for all the apps that already depend on this...

>To get to the next 64K you need to increment the
>selector by (I'm not %100 of the value) 8. The easiest way to do this is
>using the _based keyword and a far *; Something like the following.

You are pretty much assured to break if you assume anything like this.

>Now pBigSeg is pointing at the first 64 K and can move through it with ease. To
>get at the next 64K, increment BigSeg by 8, reset pBigSeg to 0 and now you
>have the next 64K. This by no means is any easier than using a huge model pointer
>but if you don't want to use the huge memory model this, or something like it
>is the only alternative.

If you are using C, you can declare pointers to be HUGE and the C
compiler  will do the right thing for you. You don't have to be huge
model.  Just like you can declare FAR pointers if you are small model, 
you can declare HUGE pointers...  There shouldn't be too many reasons
you should worry about selector tiling if you are using C since the
compiler takes care of this for you...


If you are using asm, your code should be as follows:

ExternA <__AHINCR> ; This external is exported by Windows kernel and you
                   ; will get the proper value to increment your selectors
                   ; by independent of which mode of windows you are running
                   ; (ie. real, standard, and enhanced have different values)
                   ; BTW: That's two underscores before the A.

mov ax, es	
add ax, __AHINCR ; move es up 64K or to the next selector
mov es, ax

The C compiler generates code which links to __AHINCR  exported from
Kernel so  it always works.