Wanted: A new incLean for José's WINAPI files.

[Bud Meyer]

I've come to rely on José's fantastic WINAPI files, but for some of my programs the compile time is almost 15 (!) seconds or more. While that may not seem like a long time, it's an eternity compared to the 0.1 sec compile times I'm used to when using incLean and the standard PB WINAPI. It really slows down my progress.

Is it possible to create something that would automatically generate a small lean inc file, similar to Borje Hagsten's incLean.exe? Has anyone found a trick to getting incLean to work with the new files?

[Paul Squires]

A new version of IncLean would be cool. I haven't used it in a long time (since PB started using conditional compiling in the includes). My compile times have increased as well when using Jose's includes. However, the better functionality gained by using the includes outweighs the few extra seconds. If IncLean could cut down the compile time then all the better.

[José Roca]

It depends of the files that you include. The OLE subsystem is quite large, with hundreds of files and interfaces.

If you just use the equivalent to win32api.inc, the differences aren't big.

In my computer, just including PB's win32api.inc, takes 0.8 seconds to compile.

Including my header's "windows.inc" takes 1.9 seconds to compile, but it takes 1.2 seconds if before #INCLUDE "windows.inc" you add %WIN32_LEAN_AND_MEAN = 1, and 1.1 seconds if you also add %NOSERVICE = 1. %NOMCX = 1 and %NOIME = 1.

[Bud Meyer]

Thanks. Using those equates shaved off more than 2 seconds.

[José Roca]

 
I could add many equates more, like C++ programmers usually do, and reduce dependencies, but PBer's aren't used to having to add a long list of equates and include files.

I could also reduce dependencies at the cost of clarity. For example, in commctrl.inc, I coud remove the inclusion of "Objidl.inc", that in turn causes the parsing of several other big includes, if instead of using IStream in the parameters of some ImageList functions i will use the generic IUnknown, but then, if you will need to use them, you will have to figure what interface you will have to use and what include file you have to add.

[Bud Meyer]

Well, having to search through the files to locate the right one wouldn't be any different for me since I usually have to do that anyway.

Simplicity is nice though, so I don't know if tweaking the files would be worth it or not. On the other hand, the current compile speed is a bit of a drag, and I spend much more time compiling than I do messing with the include files.

[José Roca]

The headers strictly follow the organization and dependencies of the C++ headers. Otherwise, updating them will be a nightmare. I use Windiff to compare the last SDK headers used with the new to find the differences.

Because COM was designed to be reusable, each include has many dependencies. With Windows 7 will come the Windows Ribbon Framework, a group of low-level COM interfaces, collections and callback event interfaces (forget classic Windows messages and notifications). They also make extensive use of PROPERTYKEYs and PROPVARIANTs (sort of VARIANTs on steroids). I'm afraid that I cannot ask PBer's that instead of using #INCLUDE "UIRIBBON.INC" they will have to use:

#INCLUDE ONCE "UIRIBBON.INC"
#INCLUDE ONCE "PROPIDL.INC"
#INCLUDE ONCE "OLE2.INC"
#INCLUDE ONCE "WINDOWS.INC"
#INCLUDE ONCE "WINDEF.INC"
#INCLUDE ONCE "WINNT.INC"
#INCLUDE ONCE "CTYPE.INC"
#INCLUDE ONCE "BASETSD.INC"
#INCLUDE ONCE "GUIDDEF.INC"
#INCLUDE ONCE "KTMTYPES.INC"
#INCLUDE ONCE "WINERROR.INC"
#INCLUDE ONCE "WINBASE.INC"
#INCLUDE ONCE "WINGDI.INC"
#INCLUDE ONCE "WINUSER.INC"
#INCLUDE ONCE "TVOUT.INC"
#INCLUDE ONCE "WINNLS.INC"
#INCLUDE ONCE "WINCON.INC"
#INCLUDE ONCE "WINVER.INC"
#INCLUDE ONCE "WINREG.INC"
#INCLUDE ONCE "WTYPES.INC"
#INCLUDE ONCE "REASON.INC"
#INCLUDE ONCE "WINNETWK.INC"
#INCLUDE ONCE "CDERR.INC"
#INCLUDE ONCE "DDE.INC"
#INCLUDE ONCE "DDEML.INC"
#INCLUDE ONCE "DLGS.INC"
#INCLUDE ONCE "LZEXPAND.INC"
#INCLUDE ONCE "MMSYSTEM.INC"
#INCLUDE ONCE "NB30.INC"
#INCLUDE ONCE "RPC.INC"
#INCLUDE ONCE "RPCDCE.INC"
#INCLUDE ONCE "RPCDCEP.INC"
#INCLUDE ONCE "RPCNSI.INC"
#INCLUDE ONCE "RPCASYNC.INC"
#INCLUDE ONCE "SHELLAPI.INC"
#INCLUDE ONCE "WINPERF.INC"
#INCLUDE ONCE "WINSPOOL.INC"
#INCLUDE ONCE "WINSVC.INC"
#INCLUDE ONCE "MCX.INC"
#INCLUDE ONCE "IMM.INC"
#INCLUDE ONCE "WINDOWSX.INC"
#INCLUDE ONCE "OBJBASE.INC"
#INCLUDE ONCE "UNKNWN.INC"
#INCLUDE ONCE "OAIDL.INC"
#INCLUDE ONCE "OBJIDL.INC"
#INCLUDE ONCE "CGUID.INC"
#INCLUDE ONCE "URLMON.INC"
#INCLUDE ONCE "OLEIDL.INC"
#INCLUDE ONCE "SERVPROV.INC"
#INCLUDE ONCE "MSXML.INC"
#INCLUDE ONCE "OLEAUTO.INC"
#INCLUDE ONCE "PROPVARUTIL.INC"
#INCLUDE ONCE "PROPAPI.INC"
#INCLUDE ONCE "SHTYPES.INC"
#INCLUDE ONCE "SHLWAPI.INC"

Besides, how is going a tool like FireFly to figure which include files has to add?

And we will also have to learn to write Ribbon Markup files.

Gone are the days of simple custom common controls.

Windows Ribbon Framework: http://msdn.microsoft.com/en-us/library/dd371191%28VS.85%29.aspx

[Christopher Carroll]

Thanks José for the latest update of the API.

I prefer the clarity and ease-of-use of these headers over the compilation speed. I used InClean often when using the PB headers. However, Borje never released the source code of InClean, so any version to work on these headers would have to be written from new.

[Patrice Terrier]

"Inclean" is something that should be done by the compiler itself, to avoid the inclusion of unused code.

LINK does that very well with static library...

 

[Patrice Terrier]

If i had to write a new inclean myself, here are the 4 steps i would follow up:

1 - Create a temporary file with everything put into one single file (all embedded include files) .
2 - Put my hands on Crescent Don Malin's XREF source code (must have it somewhere).
3 - Then parse the single text file, following the same XREF logic, using several hidden listbox to store retrieve the needed informations.
4 - Remove all unused SUB, FUNCTION and VARIABLES, to create the resulting cleaned source code.

Added:
I couldn't write it myself, because if i do it, then i will only take care of the SDK syntax

About the "ListBox" i would have one for "FUNCTION", one for "SUB", one for "LONG" one for "SINGLE" one for "DWORD", etc.
Storing in the 32-bit associated pointer to each of the list, the line number matching a specific item, and very important track the "count use".

...

[Jordi Vallès]

PBcodec v1.14 source code of Borje can be a good start point. I think that original Inclean has a similar structure.

[Patrice Terrier]

PBcodec, i didn't think of that one.

...

[James C. Fuller]

PBcodec, i didn't think of that one.

...

I looked at the source some time ago and found it had way too many literal strings.
I would go the regular expression route using pcre3.dll and a com server I wrote encapsulating the functions I needed.
This is the rule I used to get all sub/functions names from win32api.inc:
  sRules(1) = "(?i)declare\s+(SUB|FUNCTION)\s+(\w+)\s*"

James

[Theo Gottwald]

Of course, the best way would be, if Bob would do it.
Because at the end, only the compiler definitely knows which things are used or unused.

Therefore this would be the best way.

Everything else will be really difficult, especially if Macros are beeing used.