I am trying to access a 32-bit dll function (LoadCursorFromFile). I have set up the call from OInsight, but when I try to call the function from the script, I get an error message,"LoadCursorFromFile does not exist in USER32.DLL" although I know it does. Is this to do with 16 -] 32 bit compatability or some kind or am I just being thick?

Any ideas please.

Simon,

The short answer is that USER32 contains 32-bit functions, which cannot be called directly from 16-bit code. The long answer follows.

A DLL (or an EXE for that matter) is as much a data structure as it is executable code; the only truly "executable file" is a COM file, all the other formats (such as an EXE) require support from the operating system to be loaded, relocated, etc. Some years back, Microsoft designed a data structure which (if I remember correctly) was called the "New Executable" data structure, or "NE format" for short. This is the layout of the .DLL and .EXE files (and .FON and …) in Windows 3.x. When Windows NT (the R&D group was called the "New Technology" group, a name they gave to themselves to put the Windows 3.x group in their place … in response, the Windows 3.x group renamed themselves "Windows Revenue" since NT has never made any money) was developed, a new format, called the "Portable Executable" format, was created to hold 32-bit code and also they fixed most of the short-comings in the NE format when they created the PE format. The only problem is that they are very different structures.

The way that a program calls a DLL function is simple: it issues an x86 CALL op against a function pointer. The way it gets the function pointer is much more complex … the app developer could call LoadLibrary/GetProcAddress. But the 16-bit implementation of those functions only works against the NE format and the 32-bit implementation only works against the PE format, so it is not possible (using standard methods) to call 32-bit DLL functions from 16-bit code.

Interestingly enough, if you were to get a legal (within your process, that is) pointer to a 32-bit function, you could call it from 16-bit code … the processor associates the type (and protection level) of code with each page of memory, so it switches to 32-bit mode when you call into 32-bit code. Microsoft Windows 95 switches between 16- and 32-bit code all the time (since the "Windows" portion of Windows 95 is still 16-bit). They use some very clever mechanisms for accomplishing this, but they were nice enough to make a generic one available, called thunking. However, thunking is not for the weak of heart, and it requires knowledge of C/C++ and both 16- and 32-bit Windows development. There are a slew of very in-depth articles on the subject on the MSDN CD's (and that information is available on-line at www.microsoft.com as well).

Perhaps the best question is, what task are you trying to do with this function call?

Cameron Purdy

Revelation Software

Thanks Cameron for that detailed answer to my question. To answer the reason behind my call to this dll function is I would like some more cursors - i.e A hand that grabs a file and one that lets it go a la Drag n' Drop. Particularly in Win95 the .ANI cursor is also a nice feature. Anyway, the 16-bit 'LoadCursor' call requires that to return a cursor handle to be set by 'SetCursor(hCursor)', the cursor should be loaded from the executable's resource file (which I haven't got), while LoadCursorFromFile does not. Are the any other methods to attain this goal without the word 32-bit in it???

Thanks,

View this thread on the forum...