Using MS standard headers on PellesC

[frankie]

I spent a couple of hours to look on how to directly import native MS headers in PellesC.
The discrepancies are:

• standard headers for C99 and C11 compatibility
• Problems on Math due to C99 and C11 extensions
• An apparently misuse of pasting operators in driverspecs.h (called by winNT.h)

The first point to consider is that PellesC is strictly compliant with C99 and C11, MS VC++ not! It includes C11++ that, unfortunately is not compatible with C11. In plane words the standard header layout is completely different from that of MS, things are declared in different stdxxxx.h files and this creates some problem.
The math type complex is a basic type for C99/C11, while MS defines it as a struct. This generates errors using the MS math.h header.
In driverspecs.h there are the lines:

Code: [Select]

#define __drv_out(annotes) __post __$drv_group(##__drv_nop(annotes))
and

Code: [Select]

#define __drv_when(cond, annotes) \
  __drv_declspec("SAL_when(" SPECSTRINGIZE(cond) ")") __$drv_group(##__drv_nop(annotes))
Where the pasting operator (##) is not prepended by anything, and this is an error as stated also on MSDN help. This error produce a series of warnings of this type:

C:\PellesC\Include\winnt.h(1202): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.

The problem can be easily solved by setting off the warning using a pragma, or by modifying the original MS def in driverspecs.h as follows:

Code: [Select]

#define __drv_out(annotes) __post __$drv_group(__drv_nop(annotes))and

Code: [Select]

#define __drv_when(cond, annotes) \
  __drv_declspec("SAL_when(" SPECSTRINGIZE(cond) ")") __$drv_group(__drv_nop(annotes))

Moreover in "shellapi.h" there is this line

Code: [Select]

//          PATH                    =   c:\windows\system32;C:\windows;c:\;C:\Program Files\Compilers\
which end with a backspace that triggers the warning:

C:\PellesC\Include\shellapi.h(666): warning #1063: Single-line comment contains escaped new-line.

To solve it edit shellapi.h adding a space at the end of the line.

Anyway to use the windows headers file is possible. They can live along with PellesC, and is possible to compile using directly the standard MS headers.
Now I will explain how to, of course there will be other problems that I still have not discovered compiling my sources.
I used the SDK WIN7 SP1.

To use Headers strictly follow the instructions here.
Let me know what problems you encounter.

[TimoVJL]

Why touch to PellesC include when include path can changed as project based ?
Or in register or XML.
Maybe %PellesCDir% is important too for pomake ?

@Frankie
poide needs second copy as to new include/lib folder

\
 \bin\poide.exe
 \bin\Intl\rsrc0009.dll
 \bin\AddIns\
 \include\
 \include\Win\
 \lib
 \lib\Win\
 \lib\Win64\

other bins must be in PATH

This way we can have untouched PellesC and WSDK version in use ?

Any comments ?

[frankie]

Hi Timo,
Just because I have seen that some directories seems to be hardcoded in the compiler, or in the project files (.ppj and .ppw).
In this case when trying to compile existent projects it seems to look in the original directories 
Could you make some checks?
I have already found something to be touched in "stat.h" and "strsafe.h".
Does it works in WIN64?

[TimoVJL]

Just because I have seen that some directories seems to be hardcoded in the compiler, or in the project files (.ppj and .ppw).

Hardcoded %PellesCDir% only in poide's internal make. pomake can use %PellesCDir%.

PellesC poide with option -xml it is easy to make another copy of PellesC folder for testing environment and copy WSDK files into it. No messing with original folder at all.

[frankie]

Thanks Timo! 
I have made some more checks and discovered that is enough to replace headers in Include/Win directory.
All other files must remain that coming for PellesC distribution.
I'll write a detailed HowTo later.
Basically PellesC works with no problems with MS headers, apart the small hacking indicated in my first post and some other I have found.
For me is clear that the headers packed in the PellesC distribution are there just to install a ready to run compiler suite.
Infact the SDK's could not be redistribuited, and downloading an SDK install it and use is not so simple to explain to first time users. That's why Pelle make the decision to include a subset of headers, that IMHO are still enough unless you need a very advanced library or feature 
But the point is, considering that Pelle should know that his compiler suite could use MS headers, he has not made public the feature for at least the advanced users... 
New incompatibility are from the undeployed __declspec(selectany) and some other small issues that I'm hacking.
I have also copied new libraries in the lib folder and they works OK, unless the uuid.lib that triggers a linker error for an 'unknown codeview symbol 0x00). No problem compiling without debug information. Unless you don't need a very recent UUID you can still use the original library when compiling debuggable executables.

Last, to all PellesC users, I don't understand why nobody give any feedback. Is this issue of any interest only for me and Timo? 
(I could say that me and Timo know how to make it, so .... why do we have to waste time to write posts about it?  )
More seriously this is the main reason of irritation for Pelle, and I have to fully agree with him...

[jj2007]

Hi Frankie and Timo,

Just want to say YES, this is a good initiative, and you are doing a very good job (no thumbs up icon here - MODERATOOOOOOR!!!!!)

[DMac]

Although, I have not had need up to this point for more than what is included in the standard Pelle's download, I appreciate the fact that if I do in the future want to include some of the missing elements of the windows SDK in my applications I can refer to this thread and get things up and running quickly.

Thanks Frankie and Timo for your time and effort on this! 

JJ2007 - You can select the thumbs up from the Message icon drop down in the Post reply editor.

[frankie]

Thanks to all 
But the feedback we need is on other possible issues. I'm still looking for other drawbacks compiling and recompiling my projects that could don't include all possible headers/libraries, or the one you may have used in your application (header or library, console or GUI functions, etc.).
What we need to help us is that you experiment on your system recompiling your projects and reporting the problems if any.

[TimoVJL]

uuid.diff from PellesC uuid.lib and WSDK 7.1 uuid.lib
and uuid_1.lib generated with from WSDK uuid.lib

[jj2007]

JJ2007 - You can select the thumbs up from the Message icon drop down in the Post reply editor.

Done. The Masm forum, which also uses SMF, has a better (IMO) icon list, see here for example.

[frankie]

Thanks Timo.
Anyway the the linker problem seems to be related only to the debug section of the executable, that contains a symbol code unknown to PellesC codeview. I think this is from the new MS revisions of CodeView that are not pubblic (it's long time that MS doesn't pubblish an updated documentation). Probably a pdb reference or a new code for OLE/AUTO debuug.
So it should be safe to use it for release versions (without debugging info), or at least they can use Timo's library made with polib.

[TimoVJL]

As pocc.exe support AMD64/x64, it is possible to test those WSDK headers for 64-bit too in 32-bit environment and with x64 libs linking is possible too when 64-bit libs are copied from lib\x64 to lib\Win64  folder.

With this AddIn Create/Open 32-bit project to 64 bit project project is possible to copy to 64-bit version easily.

EDIT:
StrAlign.h line 113 without <wchar.h>

Code: [Select]

#endif // _PREFAST_
wchar_t * wcscpy(wchar_t * dst, const wchar_t * src); //<- insert this
    return wcscpy(Destination, Source);
#pragma warning(pop)
FixHdrLst.zip for testing. run it in PellesC base dir, it uses include/Win/ path and fix driverspecs.h and Stralign.h as Frankie shows.

[frankie]

Timo the insertion of wchar was already in the instructions, but the list numering was missed. It is the point 10.
I added numbering now.
The inclusion is on line 98 because if you define '_STRALIGN_USE_SECURE_CRT=1' also the function 'ua_wcscpy_s' is defined as 'wcscpy_s' and then requires whchar.h definitions.
Anyway the best place for the inclusion should be at top of the header just after the module symbole definition:

Code: [Select]

#if !defined(__STRALIGN_H_) && !defined(MIDL_PASS)
#define __STRALIGN_H_

#include <wchar.h>      //Line 46 of WIN7-sp1 SDK

Anyway considering the views and that up to now just 3 peoples downloaded the utility doesn't seem that this argument is of so big interest... 

[TimoVJL]

pobr.exe doesn't like WSDK header files
Those f... annotations

[frankie]

pobr seems to work for me 
Have you used the /W switch for windows mode?