Using MS standard headers on PellesC

[frankie]

I would like to have two tables of all the (?) header files of Pelles C and MS with the following infos:

• header file is usable by Pelles C
• header file is up to date
• file needs a C++ Compiler
• header file is a COM interface
• file is in work by [name]

Yes one of the scopes of the 'copying' tool was to keep a complete list of files, if open the zip and look inside MS-Headers.lst' you will see that you can comment-out files. With some little more code we can add a comment.

this tables should be available and editable by all of us.
Secondly, there should be a expandable list of typical errors in the MS files

• There are no comment signs '//' after endif, per example.

So every helpers can learn from the experiences of others.

And last but not least. The converted header files should be collected in an downloadable zip-file.

I do not know if this forum software is able to help in one of this points?

What about the wiki?

czerny

The limit is the platform, I don't think the forum support file condivision ...
Maybe it is too early for the wiki ... 

[frankie]

WinMerge is a good tool for comparing files / dirs.

John's error list comes from 64-bit version.

Yes Timo we can try with WinMerge.
John FindFile can be compiled in its 32 bits version?

[TimoVJL]

FindFile can compiled to both versions (64-bit after minor fix).

[frankie]

FindFile can compiled to both versions (64-bit after minor fix).

Good to hear! 

[JohnF]

Frankie,

>>at this point is more usefull to patch the standard
>>PellesC headers with the missing functionalities!

We could then distribute the headers in a zip.

John

[czerny]

Yes one of the scopes of the 'copying' tool was to keep a complete list of files, if open the zip and look inside MS-Headers.lst' you will see that you can comment-out files. With some little more code we can add a comment.

The problem will be that there are as many incarnations of this list as downloaders.
For example, what is the actual file of MS-Headers.lst? This one, included in your tool or that one posted by Timovjl?

czerny

[frankie]

Frankie,

>>at this point is more usefull to patch the standard
>>PellesC headers with the missing functionalities!

We could then distribute the headers in a zip.

John

Yes, but it will be much more complicate to define what to add ... 
Even if IMHO the average of us has never felt the need of something outside of standard PellesC distribution, there is too much stuff inside new SDK's to choose what move and what not.
My original 'hope' was that was possible to produce a kind of preheader with many #defines to use the preprocessor to autofix the MS-headers, but this proven not facible.
The fastest way is to have a compiler that is fully compatible with MSVC, but PellesC is standard compliant and MSVC not ... they could never meet 
My first need for something more was the use of COM headers that were not in PellesC, in that case the use of a preheader was working to remove annotation (yes the PRE-Fast technology  )

[frankie]

The problem will be that there are as many incarnations of this list as downloaders.
For example, what is the actual file of MS-Headers.lst? This one, included in your tool or that one posted by Timovjl?

I have put the last version, that incidentally is the Timo's version, in the attachment of the locked thread.
While we organize better let say that the locked thread is the reference.

[TimoVJL]

In my link should be MS-HeaderFix.lst only in FixHdrLst.zip ?

Can anyone figure out why this works with msado15.h / adoint.h ?

Code: [Select]

...
#define ADOErrors Errors
#define ADOError Error
#define ADOProperties Properties
#define _ADOConnection _Connection
#define _ADORecordset _Recordset
#define _ADOParameters _Parameters
#define _ADOParameter _Parameter
#define ADOParameters Parameters
#define _ADOCommand _Command
#define _ADORecord _Record
#define ADOFields Fields
#define ADOField Field
#define _ADOStream _Stream
#define ADOProperty Property
#include <msado15.h>
...


[Stefan Pendl]

An SVN repository or similar would be the best to allow smooth collaboration in this project.

You have all you need:

• users can lock files they work on, so no two users will work on the same file
• easy update and commit of changes
• etc.

[TimoVJL]

Here are old WinMerge.exe and patch.exe.

Example in unified mode:

Code: [Select]

--- include\Win.SDK\StrAlign.h
+++ include\Win\StrAlign.h
@@ -42,6 +42,7 @@
 
 #if !defined(__STRALIGN_H_) && !defined(MIDL_PASS)
 #define __STRALIGN_H_
+#include <wchar.h>
 
 #ifndef _STRALIGN_USE_SECURE_CRT
 #if defined(__GOT_SECURE_LIB__) && __GOT_SECURE_LIB__ >= 200402L

Code: [Select]

patch.exe -u include\Win\StrAlign.h StrAlign.h.diff

[frankie]

Timo what about to use all GNU-Win tools?
We can compile them in source and merge in the tool so it can do anything in one pass: backup the system, copy files and patch them. 
Anyway the things changed very fast, a new release of compiler has been deployed, and from I can read many bugs have been removed and more functionalities have been added.
I.e when pelle say
Added #pragma default_convention() to deal with annoying third-party header files.
what is the side effect on MS-headers?
EDIT: That's just for headers that miss the correct calling convention (to avoid to patch all functions call).

Unfortunately I only have an XP-PE32 machine for all my jobs (and don't want take more with me around the world) I can't take a look to the new version not even to documentation (refuses to install on XP).
So I'm considering:

• Is this just a waste of time? Maybe new version doesn't need patching or not made this way...
• All the patches we have found and fixed, showed on the locked thread, have a sense? We are blindly patching headers were the presence of polymorphism clearly shows that that files are intended for C++ (the patches applied permit to use them from plain C  , but are the majority of us able to use them?). Will they be of any use? Who tested any program that needs them?
• In the new release Pelle added some more headers maybe they are enough?
• Some patches relative to zero size arrays are plain C class trnslations, while the patches remove the warnings are the structure functional? who take care of verify if they works? There are many ways to patch this kind of declaration is the chosed one the correct one?

Maybe we have to complete the tool and made it working on the base set of headers, then add something else when it use is requested...

[TimoVJL]

For someone who just want to just test WSDK with separated copy of PellesC.
make these changes to Pellesc ctype.h

#ifdef _MSC_EXTENSIONS
/* for compiling with windows.h -- see Microsoft ctype.h */
#ifndef _WCHAR_T_DEFINED
#define _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#include <wchar.h>
#endif
#pragma warn(disable: 1058 1063) // <-- add this for MS bugs
#ifdef _WIN64
#pragma warn(disable: 2195) // <-- add this for 64 bit
#endif
#endif /* _MSC_EXTENSIONS */

and copy WSDK headers with frankie's tool and libs manually.

[frankie]

I had a look over the new release of PellesC, as far as I can see the project scope is still valid.
The compiler seems to be more logorroic ( joke) I got more warnings on already patched files.
I'll go on...

[JohnF]

Frankie,

Would it not be easier to identify which bits are missing (and worth while) and then add those bits to Pelle's headers.

EDIT: For the PellesC headers that already exist of course.

John