WIN32API.INC update

[Lance Edmonds]

Folks, just so you are aware, the WIN32API.INC file set has been updated quite a few times over the past week or two.

If your WIN2API.INC file is dated 6 July 2001 or earlier, please be sure to download the latest file set from http://www.powerbasic.com/files/pub/pbwin/win32api.zip

Thanks!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Guest]

Lance, are you folks going to add this one?

 
Declare Function InitializeCriticalSectionAndSpinCount LIB "KERNEL32.DLL" _
    ALIAS "InitializeCriticalSectionAndSpinCount" (lpCriticalSection AS _
    CRITICAL_SECTION, ByVal SpinCount As Long) As Long

[This message has been edited by Ron Pierce (edited July 10, 2001).]

[Lance Edmonds]

Quite possibly.

Needs Win98 or better though, and SetCriticalSectionSpinCount() is NT/2000 only.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Guest]

Thanks! I keep having to move these to newer API files but that isn't much pain.

[John Hutchins]

Lance,

DECLARE FUNCTION QueryPerformanceCounter LIB "KERNEL32.DLL" _
ALIAS "QueryPerformanceCounter" (lpPerformanceCount AS LARGE_INTEGER) AS LONG

DECLARE FUNCTION QueryPerformanceFrequency LIB "KERNEL32.DLL" _
ALIAS "QueryPerformanceFrequency" (lpFrequency AS LARGE_INTEGER) AS LONG

Are the LARGE_INTEGER'supposed to be QUAD's

------------------

[Lance Edmonds]

A LARGE_INTEGER in PowerBASIC usually looks like this (of course, you could substitute a QUAD if it makes things easier for you, or you could create a UNION).

TYPE LARGE_INTEGER
  lowpart AS DWORD
  highpart AS LONG
END TYPE

' example implementation of a Union 
UNION PBLARGE_INTEGER
   LI AS LARGE_INTEGER
   QU AS QUAD
END UNION

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Knuth Konrad]

Lance,

this block is twice in RESOURCE.H. I'm not that familiar with resource files but I guess once should be enough.

#define VOS__BASE 0x00000000L
#define VOS__WINDOWS16 0x00000001L
#define VOS__PM16 0x00000002L
#define VOS__PM32 0x00000003L
#define VOS__WINDOWS32 0x00000004L

Knuth

------------------
http://www.softAware.de

[Lance Edmonds]

Thanks! I'll see about getting that fixed ASAP. Well spotted!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Uhhh.. actually it turns out that those are not duplicated as such... one set uses one underscore, the other uses two.

The RESOURCE.H file includes both for utmost compatibility.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Borje Hagsten]

Just wanted to send a big THANK YOU to the PB staff for keeping this
file updated, and an extra big thanks for the log, History.txt


------------------

[mark smit]

Hey Lance,

how about these...

%DC_BRUSH = 18
%DC_PEN   = 19
 
declare function SetDCPenColor lib "GDI32.DLL" alias "SetDCPenColor" (byval hDC as long,byval crColor as long) as long
declare function SetDCBrushColor lib "GDI32.DLL" alias "SetDCBrushColor" (byval hDC as long,byval crColor as long) as long

------------------
Cheers!

[Fred Buffington]

So Lance does that mean I shouldn't use it on my Win95 machine ?

------------------

[Lance Edmonds]

Use what? The API's mentioned near the top of this thread?

If you do implicitly (load-time) link your app to an API that is not supported for a particular Win32 platform, one of two things will happen when the app is launched:

• You'll get a Windows error "The application is linked to a missing export in xxxx.DLL", and the app will not be launched.
  
  or:
  
• The O/S may export the particular API, but do/return nothing, and in some cases, GetLastError() will return a "not supported" error.

In such cases where you want your app to run on all Win32 platforms, you need to use explicit (or run-time) linking (LoadLibrary/GetProcAddress/CALL DWORD/FreeLibrary/etc). In such cases, you would probably exclude certain functionality according to the O/S version number (or if return from GetProcAddress was zero).

For example, using GetDiskFreeSpace() will work on all Win32 platforms, but GetDiskFreeSpaceEx() is only available from Win95/OSR2 onwards. The former works on drives up to 2Gb, the latter reports larger drive stats.

In order to make your app work under Win95a, you'd use the explicit linking method. Your would tailor your app's behavior according to the availability of the API.

Clear as mud?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Cecil Williams]

Lance,

Easy question for ya. Just how BIIIIIIIIIIIIIIIIG is the
Win32api going to get before it's broken down into modules???
The latest version is clocking in at 800k+ and from all
indications from above, will only mushroom from this point.

Surely, the plan would be to break down the main file into
smaller includes for maintainability. I believe someone
had already mentioned this route to take, and hopefully
sometime in the future this will take place.

Cheers,
Cecil

------------------

[Lance Edmonds]

"Mushroom" is probably a relative overstatement, however, the API #INCLUDE file set is already split into several groups (COMMCTRL, COMDLG32, etc). There are no immediate plans to split the largest file (WIN32API.INC) mostly because of the ease of use that just one #INCLUDE statement offers.

However, this situation may change... who knows what the future will bring!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Gregery D Engle]

Lance,

Maybe you should offer Include files split up like in CPP. It
would be nice to know when comparing MSDN

------------------
-Greg

[mark smit]

Put another tick down for me. I would love to see the Win32api split into smaller modules. It would be SOOO nice to have headers that would accuratly reflect the SDK/MSDN.

------------------
Cheers!

[Edwin Knoppert]

I don't!

------------------

[Cecil Williams]

You don't what Edwin????

I'll just reiterate what someone else proposed.

The main Win32API.inc would still be one include in the
main module. Could be broken down as follows:

File Win32API.inc ->

    #include user32.inc
    #include gdi32.inc
    #include kernel32.inc

    and so on.

There, was that so hard??? This way it flows like the standard
SDK for Windows API32.

Then for all the additional inc's not considered as part of the
standard Windows.h header file, just treat them like the common
controls, common dialog, etc., just expand as required.

Cheers,
Cecil


------------------

[Lance Edmonds]

Cecil, may I make a suggestion...

How about writing a small program to spilt the WIN32API.INC file by Sub/Function by DLL name?

Once you write the program, you'll be set for life!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>