Using MS standard headers on PellesC

[frankie]

It seems to be normal   
MS headers have alot of this, just google "windef.h redefinition of hiword".
On MS compiler a macro redefinition is just a warning, so MS, and the users, don't care much about it 

Anyway to fix:

Code: [Select]

#define LOWORD(_dw)     ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#define HIWORD(_dw)     ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))
Simply add:

Code: [Select]

#ifndef LOWORD
#define LOWORD(_dw)     ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#endif
#ifndef HIWORD
#define HIWORD(_dw)     ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))
#endif

Or... comment them out

[CommonTater]

You cannot simply include all headers, many of them are C++ only (as gdiplus.h) and other specialized for object programming embedded in the MSVC compilers. You will never ever can put all MS headers in a plain C compiler (PellesC or whatever...)

Ok... so how about we start by making a list of headers that cannot be converted. 
 

[CommonTater]

It seems to be normal   
MS headers have alot of this, just google "windef.h redefinition of hiword".
On MS compiler a macro redefinition is just a warning, so MS, and the users, don't care much about it 

Anyway to fix:

Code: [Select]

#define LOWORD(_dw)     ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#define HIWORD(_dw)     ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))
Simply add:

Code: [Select]

#ifndef LOWORD
#define LOWORD(_dw)     ((WORD)(((DWORD_PTR)(_dw)) & 0xffff))
#endif
#ifndef HIWORD
#define HIWORD(_dw)     ((WORD)((((DWORD_PTR)(_dw)) >> 16) & 0xffff))
#endif

Or... comment them out

See... you're already modifying headers... BUT, where is the documentation on this, how do we know what to modify in each header for correct behaviour? 
 
Some of Pelles headers have not been updated since Win2000.  There are entire blocks of functionality missing (COM, being the most glaring omission), apparently there are now a number of headers that cannot be converted...
 
If Pelles is going to claim compatibility, at the very least he should be documenting the incompatibilities...
 

[frankie]

Dear Tater,
I really don't understand the point 
Let resume:
Nobody contested your experience (I'm not interested to make public the mine) but let say we are both skilled 
We (not only me, but who cooperated in this thread) find a solution.
All my projects work with no problems.
I wrote down the howto, but you moved in a differnt way, made a cauldron of headers, made for a C/C++ compiler, and expected that they works together? 
Have you tryied to compile something following the instructions?

Duplicate my test bed... start working through the errors... you will find that most headers need massive changes including redefinition of variable types, inclusion of CRT headers and so on to work.  If POCC didn't stop at 100 errors, my little test bed would produce tens of thousands of errors.

Duplicate us test bed and check it works? 

Pelles C does not work happily with untouched MS headers.  That you can compile some little program using a couple of headers and a message box with the Windows.h header does not imply anything other than the Windows.h header contains nothing that needs conversion... that you got lucky.

What means? You were unlucky? I'm just lucky?? I close my eyes and write technical answers by pounching the keyboard in hope that words having any sense come out?? 

But you said we can... You've been insisting that Pelles C works with untouched headers...

But at least to be aware of what you are including? 

You are free to follow a different way, to have a different mind  We are in a free world (at least our countries are supposed to be so), but the respect is the the base of any interpersonal relation.

As I said what I have done is enough for me, I will give help to solve problems that can come out, but don't see any more development necessary.
If you will define a different strategy that shows something working I will be honoured to partecipate to the development 
Bring me up Scotty I will give all the help.

See... you're already modifying headers... BUT, where is the documentation on this, how do we know what to modify in each header for correct behaviour?

Is where I have found it on the net, try googling.... 

As last consideration doesn't seem to you that you are getting a little bit .... trollish...  it seems LD Blake words
I'm jocking of course. 

[CommonTater]

Dear Tater,
I really don't understand the point 

I'd say that's getting rather obvious.
 

Let resume:
Nobody contested your experience (I'm not interested to make public the mine) but let say we are both skilled 
We (not only me, but who cooperated in this thread) find a solution.
All my projects work with no problems.

But what are your Pelles C projects?  IIRC, you once told us that for anything "serious" you use Delphi.  So I'm going to take a guess that you use Pelles like most people do... quick jobs, support dlls and the occasional console program.
 
Yes it is likely you can either use as-is or easily convert quite a few of the headers for such simple tasks... For example, if I have a small GUI project that needs only Windows.h and maybe Commcrtl.h I can convert those headers in minutes... In fact I've done several on my own. 
 
However; when things get serious --like in a big project-- the only smart answer is to head for a different compiler because you're either going to hit the limits of Pelles C or you're going to find yourself in this quagmire of converting headers with little or no documentation.
 
Now, let me be perfectly plain about this... here's my cards on the table...
 
With the exception of a stack management issue I idetified last year...
 
http://forum.pellesc.de/index.php?topic=5077.0
 
... I happen to think that Pelles C, and POIDE are the bees knees.  There is no better compiler and IDE on the net at any price. I like Pelles C I really do.
 
However; with the Windows API being omissive and now becomming outdated, I find myself struggling to do stuff that should be "advanced" but possible. COM is one example but there are several others. 
 
My suggestion here is that we (including Pelle) do one of three things:
 

• Admit and publish the limitations of the package.  (which is happening now)
• Get busy and fill out the missing functionality.
• Let Pelles C die a rather ugly and uncermonious death.

Personally I'm favouring #2 since I would like to continue working in plain C but with the fullness of the Windows API.
 
Most of the Object Oriented headers (COM, DirectX, etc) from MS include C compatible interfaces in their bodies. (GDIPLUS being a noteworthy exception) It should thus be possible to use them with Pelles C... but there is some unknown thing that is preventing this.  It seems that no matter what I do I can't get them to work... and the question is "Why?"... what aren't we being told? 
 
If that documentation were here on the forums, in some comprehensive form, I would be more than happy to do the conversions and upload the new headers and libs... no problem.
 
Instead we've got you and timo --both better programmers than I-- talking over our heads and saying you know how to do it so it should not be a problem... But if an individual does not know how to do it, no amount of telling us it can be done is going to help.
 

I wrote down the howto, but you moved in a differnt way, made a cauldron of headers, made for a C/C++ compiler, and expected that they works together? 

My test bed is a starting point from which to build a catalogue of which headers can and cannot be converted, and what changes are needed to make them work.  I don't claim it solves the problem, it is merely a tool for examining the problem.
 

Have you tryied to compile something following the instructions?

Yes... I did.  It will compile a few simple things like my little backup program or my file integrity scanner... but when unleashed on anything of even moderate complexity like my HTPC remote control or build script tool it falls flat on it's face. 
 
It works with the headers you used... but that is not a general purpose improvement, it's a very specific example.
 

But you said we can... You've been insisting that Pelles C works with untouched headers...

But at least to be aware of what you are including?

Right... as I said the first step is to compile a list of headers and libs that cannot be converted because they are for C++ or C# or whatever... We then eliminate them from my mass include and carry on...
 
The goal is not to find some example to prove it works... the goal is to fix all the things that prevent it from working.
 

As I said what I have done is enough for me, I will give help to solve problems that can come out, but don't see any more development necessary.

So you've made some minor contribution and now you think it's all over and done with?
 
Thanks.
 

If you will define a different strategy that shows something working I will be honoured to partecipate to the development 

Does it not occur to you that it is just as important to know what does not work?
 
We know you can't just switch the project folders and go for it... that is 100% painfully obvious... so we start by making a list of what does not work and then figuring out how to fix it.
 
Showing that some small subset does work accomplishes absolutely nothing.
 
 

As last consideration doesn't seem to you that you are getting a little bit .... trollish...  it seems LD Blake words
I'm jocking of course. 

Yes, I am being assertive. Ever since version 2.90 I've been pressing gently for better Windows API support, either by adding more stuff to the basic distribution or by converting MS headers after the fact... so far all I've seen is a bunch of trivial examples of something that does work. That's not problem solving... that's showing off.
 
 
 

[frankie]

Dear Tater,
I'm travelling and couldn't answer more up to tomorrow.
But I would clarify some points (I will not quote things).
I like unlucky people like me need to work to live, so unfortunately I don't have so much time as required by a so huge job like the one you are proposing.
PellesC is a plain C standard compliant compiler, and many things simply cannot be done with it (because are not std compliant or because are not plain C). Yes there will be tricky ways, but they will never be orghanic hackings. If you need that particular features you have to switch to MSVC.
Why you always point out your competence? Nobody want to diminuish you, why you put on the defense?
You always ask for documentation and for more explanation on how to do it, it's a no sense, I don't know how to do it. Give me a problem and I'll try to solve it.
I'm not better than you, but with a different experience. I worked a lot inside the OS's than outside. I'm sure that you can write more faster, and much better, than me a complex GUI application (by the way I don't use Delphi, while I used a lot of languages, Delphi is not in my software, maybe you confused me with someone else).
If you tryied to write a code that uses headers that creates problem could you post a small project so we all together could take a look at it and maybe found a general solution that solves also other problems?

Last, please don't be hungry with Pelle and its tool. Pelle wrote it, a little bit for fun and a little bit for utility, to sell for special applications that requires standard compliance. And made a very good job, but is his compiler, and he has the last word on how it must work. He also decided to donate free usage to anybody asking in change only voluntarily contribution and help to test it.

[CommonTater]

But I would clarify some points (I will not quote things).
I like unlucky people like me need to work to live, so unfortunately I don't have so much time as required by a so huge job like the one you are proposing.

There seem to be a couple of choices here... One guy working alone puts in 1,000 hours on this or 100 people working together each put in 10 hours.  Nobody is saying YOU have to do this... In fact, I'm answering your appeal for help and cooperation.
 

PellesC is a plain C standard compliant compiler, and many things simply cannot be done with it (because are not std compliant or because are not plain C).

Yes I know that... but there is more that can be done than is included in the standard distribution.
 

Yes there will be tricky ways, but they will never be orghanic hackings. If you need that particular features you have to switch to MSVC.

Ok, thanks for the help, see you around... 
 

Why you always point out your competence? Nobody want to diminuish you, why you put on the defense?

You and I know what we can do but we are not the only two people reading this. Someone who's contemplating jumping to this as a project should have some idea of the skills of the other members, don't you think?
 

You always ask for documentation and for more explanation on how to do it, it's a no sense, I don't know how to do it. Give me a problem and I'll try to solve it.

Ok... so none of us knows how to do it... Does that not strike you as a good time to ask for instructions?
 

I'm not better than you, but with a different experience. I worked a lot inside the OS's than outside. I'm sure that you can write more faster, and much better, than me a complex GUI application.

I doubt it... I've always respected your skills and whether you know it or not you've helped me quite a bit over the years.
 

If you tryied to write a code that uses headers that creates problem could you post a small project so we all together could take a look at it and maybe found a general solution that solves also other problems?

OK... when I take my test bed and modify the Hello_SDK program like this...

Code: [Select]

// hello world to test sdk headers
// set project folders to SDK folders
#include <stdio.h>
//#include "\WinAPI\AllHeaders.h"

#include <windows.h>

int _cdecl main(void)
  {
    puts("Hello SDK User!\n");
    return 0;
  }

... so it includes only Windows.h
 
I get the following error cascade...
Building main.obj.
  L:\WinApi\Include\winnt.h(1202): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winnt.h(12880): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winnt.h(13305): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2935): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2938): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2941): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3053): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3056): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3059): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3062): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winuser.h(3181): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winreg.h(1242): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winreg.h(1256): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\shellapi.h(666): warning #1063: Single-line comment contains escaped new-line.
L:\WinApi\Include\objbase.h(865): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\stralign.h(113): warning #2018: Undeclared function 'wcscpy'; assuming 'extern' returning 'int'.
L:\WinApi\Include\stralign.h(113): error #2060: Invalid return type; expected 'wchar_t *' but found 'int'. *** Error code: 1 ***
Done.
 
I've been chasing these warnings and the final error all morning without much success...
It is NOT obvious how the Invalid token is being produced... But I'm guessing it's a point source error since it is so frequent... any idea where?  any idea how to fix it?
 

Last, please don't be hungry with Pelle and its tool. Pelle wrote it, a little bit for fun and a little bit for utility, to sell for special applications that requires standard compliance. And made a very good job, but is his compiler, and he has the last word on how it must work. He also decided to donate free usage to anybody asking in change only voluntarily contribution and help to test it.

Sigh... I know all that...
 
But, for a minute, look at the activity on other forums --the D forum is a good example-- and see the users working out issues, contributing new stuff, expanding the project... Why is it wrong to do that here?
 
Seriously... If Pelle wants to tell me to "leave it alone", I will.  I'll do what you say and switch myself over to a different compiler... but only an idiot would tell contributing users to piss off.  Pelle's genius should be complimented by people seeking to add or improve things...
 

[CommonTater]

Is there no one who wants to help out with this?
 
The goal is to fill out the Windows API for Pelles C... is that not worth a little time?
 
 

[TimoVJL]

MS-Headers.lst, some c++ headers removed.

MS should start fixing their headers too, xenroll.h

Code: [Select]

#ifdef __cplusplus

class DECLSPEC_UUID("43F8F289-7A20-11D0-8F06-00C04FC295E1")
CEnroll;
#endif
#endif /* __XENROLLLib_LIBRARY_DEFINED__ */

/* interface __MIDL_itf_xenroll_0000_0007 */
/* [local] */

extern "C" IEnroll * WINAPI PIEnrollGetNoCOM(void);
extern "C" IEnroll2 * WINAPI PIEnroll2GetNoCOM(void);
extern "C" IEnroll4 * WINAPI PIEnroll4GetNoCOM(void);


[frankie]

... so it includes only Windows.h
 
I get the following error cascade...
Building main.obj.
  L:\WinApi\Include\winnt.h(1202): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winnt.h(12880): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winnt.h(13305): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2935): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2938): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(2941): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3053): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3056): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3059): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winbase.h(3062): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winuser.h(3181): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winreg.h(1242): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\winreg.h(1256): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\shellapi.h(666): warning #1063: Single-line comment contains escaped new-line.
L:\WinApi\Include\objbase.h(865): warning #1058: Invalid token produced by ##, from '(' and '__drv_nop'.
L:\WinApi\Include\stralign.h(113): warning #2018: Undeclared function 'wcscpy'; assuming 'extern' returning 'int'.
L:\WinApi\Include\stralign.h(113): error #2060: Invalid return type; expected 'wchar_t *' but found 'int'. *** Error code: 1 ***
Done.
 
I've been chasing these warnings and the final error all morning without much success...
It is NOT obvious how the Invalid token is being produced... But I'm guessing it's a point source error since it is so frequent... any idea where?  any idea how to fix it?

Hi Tater,
but have you read this?
Sure?

[frankie]

MS-Headers.lst, some c++ headers removed.

Thanks Timo Good job.
I have updated the tool with your list.

If you have time, and are happy with it maybe can add to the tool a small text substitution routine for the small fixing we have found. Seems that the notes about the patches are not very clear.

MS should start fixing their headers too

Yes  You're right 

I have update the instructions adding the fixing for 'Xenroll.h' (point 11), and killed the warning for __declspec(selectany) (point 12) by defining it as nothing (selectany make sense generally only for C++ that can duplicate constructors and destructors more than one time).

[CommonTater]

Hi Tater,
but have you read this?
Sure?

Yes I read it ... No one does not fix problems by ignoring them. 
 
Turning off the warning is not the way to do this... eventually you will  have turned off enough warnings that you will find yourself in a situation where a warning that should have been heeded is not delivered.
 
 

[JohnF]

I agree with Tater, to do the job properly is huge task - I've messed with various MS headers in the past and this one is one that I hesitate to start (getting old, brain power is decreasing). Ideally an automated process is needed especially for beginners, plus, as new headers are added the automated process would hopefully deal with the additions.

John

[TimoVJL]

SDK Error list to check.
Many errors was caused by missing header before or wrong order to include.
Most error are just by redeclaration.

[EdPellesC99]

Great to see you back Tater.
Long live our forum (upstart) member in his current (but former) incarnation !

Welcome back home.

Ed