NO

Author Topic: Using MS standard headers on PellesC  (Read 19872 times)

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 1555
Re: Using MS standard headers on PellesC
« Reply #15 on: April 02, 2014, 12:19:35 PM »
For example, if someone write MessageBox( and what (s)he see ?

With WSDK:
WINUSERAPI int WINAPI MessageBoxA( __in_opt HWND hWnd,

With PellesC headers:
int MessageBoxA(HWND hWnd, LPCSTR lpText, LPCSTR lpCaption, UINT uType)
May the source be with you

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1572
Re: Using MS standard headers on PellesC
« Reply #16 on: April 02, 2014, 01:48:38 PM »
I see...  >:(
But this is more a bug of PellesC Info Browser than a problem with annotations...
Why the browser stops including text?  >:(
Is the same problem that I get when I write a more complex piece of code, moreover the browser aborts silently an you have no more browse info anyywhere. Even the functions pane doesn't show all functions in the file >:(
« Last Edit: April 02, 2014, 01:51:54 PM by frankie »

CommonTater

  • Guest
Re: Using MS standard headers on PellesC
« Reply #17 on: April 02, 2014, 04:39:01 PM »
Well, finally back with my old user name... Didn't much like having my real name up there for everyone to see.

Anyway... You're going to run into stuff like this a fair bit. Some apparently minor thing will fester itself into a full blown deal breaker. As I'm sure you know I've tried doing this several times over the years, never with much success.

You have two problems here... Headers and Libs.  Even if you get the headers to load up error free (bearing in mind that "Compiles" does not imply "Works") you're still going to have the problem of missing imports from the Pelles C libs.  Windows API has added more than 500 new calls since most of those libs were created so simply importing the headers is not going to give us magical access to the newer imports in the 2010 and 2013 SDK, we'll just end up with a huge mess of linker errors.

What I'd really like to see is a tool like they had for Turbo Pascal and later for Delphi that would basically read and transform the Windows headers automatically.  Granted the transformation was not 100% but the issues were relatively minor and could be dealt with as we found them.  Since the transforms from VC++ to Pelles C are far simpler than from VC++ to Pascal I see no reason this can't be done.

Ideally, downloading PellesC would not include Windows Develpment (headers and libs) at all. Instead, we would get command line tools and scripts (.bat?) to read the SDK headers and libs and transform/import them automagically at install time.  If we got a newer copy of the SDK, just run the script again and we're all up to date.  For Pelle this simplifies his updates since he now only needs to update the utility, not the headers and libs themselves.

But the only person who knows exactly how to do it is Pelle and he remains (strangely) silent...





Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 1555
Re: Using MS standard headers on PellesC
« Reply #18 on: April 02, 2014, 06:15:42 PM »
Welcome CommonTater :D

Have you now working PellesC environment for WSDK 7.1 ?
What libraries makes you those harms ?

What real problems are ?
Is some where open source project to test against problems ?

--Timo

BTW: those who want to tackle with WSDK8:
Code: [Select]
#include <excpt.h>

typedef
_IRQL_requires_same_
_Function_class_(EXCEPTION_ROUTINE)
EXCEPTION_DISPOSITION
NTAPI
EXCEPTION_ROUTINE (
    _Inout_ struct _EXCEPTION_RECORD *ExceptionRecord,
    _In_ PVOID EstablisherFrame,
    _Inout_ struct _CONTEXT *ContextRecord,
    _In_ PVOID DispatcherContext
    );

typedef EXCEPTION_ROUTINE *PEXCEPTION_ROUTINE;
very nice C code, isn't shit ?
« Last Edit: April 02, 2014, 06:25:56 PM by timovjl »
May the source be with you

CommonTater

  • Guest
Re: Using MS standard headers on PellesC
« Reply #19 on: April 02, 2014, 06:35:27 PM »
Welcome CommonTater :D

Thanks...

Nope, still not getting it to work.  I'm going to try Frankie's little tool later today.
 
But, as I point out, merely importing the headers is not sufficient. If we are bringing in new functionality (say, DRM, for example) we're going to have to translate the libs for it as well.
 
This is why I suggested a tool that does this automagically. It's a huge and tedious job and if we can automate at least the common changes it's going to save people a lot of time.
 
It would also help if we could put together a downloadable list of headers, with known changes that we can use as a starting reference.  Listing them in the forum is ok, but eventually that can become a tedious and confusing search. 
 
Something with the name, the line number and replacement line like...

   msheader.h (100)  \\ path = d:\ \n
   msother.h (5655)  PWCHAR ptufunc(WCHAR test);\n

... and so on, would be an enormous help.
 
Done correctely this could eventually become a translation script to be read and applied by a conversion tool.  Initially it will be a real pain to put together but over time with user contributions, it could become quite comprehensive.
 
Similarly it should be possible to automate the #pragma comment(lib... statements Pelle and I added for version 2.9 ... since we are going to transform the libs we can just as easily build a database of which imports are in which lib and correlate that against headers, automatically inserting the pragmas to maintain this very nice functionality.
 
I'm willing to help where I can... but being mostly an applications guy, this is just on the edge of what I know how to do.
 
« Last Edit: April 02, 2014, 07:17:12 PM by CommonTater »

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 1555
Re: Using MS standard headers on PellesC
« Reply #20 on: April 02, 2014, 07:00:52 PM »
Can't you least try separated WSDK environment for testing ?
After that tell us those problems.
Frankie made good work for that already.

May the source be with you

CommonTater

  • Guest
Re: Using MS standard headers on PellesC
« Reply #21 on: April 02, 2014, 07:21:19 PM »
Can't you least try separated WSDK environment for testing ?
After that tell us those problems.
Frankie made good work for that already.

Of course. As I find stuff I will let you know.

But, as I said, the goal is to build some kind of comprehensive documentation. 

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 1555
Re: Using MS standard headers on PellesC
« Reply #22 on: April 02, 2014, 07:41:43 PM »
These folders are in my WSDK test:
Code: [Select]
C:\code1\PellesC
├───bin
│   ├───AddIns
│   ├───AddIns64
│   ├───Help
│   └───Intl
├───include
│   └───Win
│       └───gl
└───lib
    ├───Win
    └───Win64
in bin folder
Code: [Select]
cformat.dll
cformat64.dll
idespawn.exe
idespawn64.exe
pobr.dll
pobr.exe
pobr64.dll
pocc.exe
poide.exe
poide64.exe
polib.exe
polink.exe
pomake.exe
porc.dll
porc.exe
porc64.dll
porc64.exe
sqlite3.dll
sqlite364.dll
support.dll
support64.dll
sysdefs.tag
in bin\Intl folder
Code: [Select]
rsrc0009.dllStart with that and use poide -x -xml option
May the source be with you

CommonTater

  • Guest
Re: Using MS standard headers on PellesC
« Reply #23 on: April 02, 2014, 07:49:07 PM »
For me is clear that the headers packed in the PellesC distribution are there just to install a ready to run compiler suite.

Hense my oft repeated suggestion that we should treat the Windows API part of the project as a mere starting point, not as a final be all and end all.  There is a LOT of stuff missing... COM, DShow, DirectX and more.
 
Quote

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  :P

Well, not so advanced. For example: It's not possible to write a Media Player in Pelles C without resorting to MCI which will eventually be removed by MS.

Quote
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...  :o

And more importantly, he knows what has to be done to convert the API for compatibility with his compiler and this information is not available anywhere.

BUT... and this is crucial... What we should really should want to do is use Pelles CRT and extension libs with the Windows API headers.  We should see his distribution of Pelles C as one thing and the Windows API headers and libs as something separate.  It's not enough to get it working with all MS headers including their CRT... we actually do need to convert the headers to work with Pelles CRT as we go. This might mean changing some variable types, modifying typedefs and so on.  It's not a simple matter of changing folders in the project settings.

Quote
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.

The best bet here is to take all the SDK libs and remove debugging code.  As it is now, we can't debug track into any of the libs as it is... so this would not be a loss.  It would however give us access to new imports in those libs that are not in Pelles libs. 


Quote
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?  :-\

Nope... I'm betting this is a matter of concern for every last one of us. Who doesn't want a complete set of Windows API headers and libs? 

The big bugaboo with this right now is that most people are probably sitting back waiting to see how badly this fails before getting involved... and of course that is what will cause the ultimate failure.

I'm here now and I will help you any way I can but as I've already noted, some of this stuff is clearly beyond my current skills... But I will help as much as I can.

CommonTater

  • Guest
Re: Using MS standard headers on PellesC
« Reply #24 on: April 02, 2014, 07:56:27 PM »
These folders are in my WSDK test:
Start with that and use poide -x -xml option

Sounds like a plan.  I have the 7.0 sdk headers and libs in a zip file (BIG zip file) so it's no problem for me to put them wherever they're needed.
 
I have a couple of quick service calls to run this afternoon but this evening I will begin testing...
 
 
And for everyone else ... the more the merrier.  Lets get this done!

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 1555
Re: Using MS standard headers on PellesC
« Reply #25 on: April 02, 2014, 09:29:40 PM »
For those who still don't know that it is possible to run several versions of PellesC in same machine with commandline options -x -xml.

Just try to do same with Microsoft Visual Studio with /useenv and have some fun (wet day dreams)?
I have PellesC versions 2.50 - 7.0 for testing in same machine.
Versions before 5 must handle register between sessions.
Just ask details to do that.

EDIT: create empty sysdefs.tag to PellesC\bin folder for new headers.
« Last Edit: April 14, 2014, 10:24:33 AM by TimoVJL »
May the source be with you

CommonTater

  • Guest
Creating a test bed for SDK 7.1 headers
« Reply #26 on: April 03, 2014, 04:27:57 AM »
As promised I've started working in earnest on this problem of getting the SDK headers and libs to work in PellesC.  The first step is to create a test bed...
 
I took a nice empty flash drive and installed a copy of Pelles C x64 on it without the "Windows Development" option so that I had only the tools and CRT... no API headers or libs.
 
Thanks to the heads up from Timo, I got it working independently of the main copy on my hard disk by using the -X and -XML settings.xml options.
 
Next I installed the Windows SDK version 7.1 and selected only the Windows API headers and libs. These I copied to the flash drive in a folder named WinAPI (of course).
 
Finally I made a backup of the whole thing, since I am going to mess with it horridly...
This produced a tree like this....

L:.
├───backup
│   ├───PellesC
│   │   ├───Bin
│   │   │   ├───AddIns64
│   │   │   ├───Help
│   │   │   ├───Intl
│   │   │   └───Wizards64
│   │   ├───Include
│   │   │   └───sys
│   │   └───Lib
│   │       ├───Win
│   │       └───Win64
│   └───WinApi
│       ├───Include
│       │   └───gl
│       ├───Lib32
│       └───Lib64
├───PellesC
│   ├───Bin
│   │   ├───AddIns64
│   │   ├───Help
│   │   ├───Intl
│   │   └───Wizards64
│   ├───Include
│   │   └───sys
│   └───Lib
│       ├───Win
│       └───Win64
├───Projects
│   ├───hello_sdk
│   │   └───output
│   ├───make_all_hdr
│   │   └───output
│   └───Ms-Headers
└───WinApi
    ├───Include
    │   └───gl
    ├───Lib32
    └───Lib64

 
The most obvious way to test this is to write some silly little project and include all 1800+ headers...
(I'm not worried about the libs yet)
 
So now I needed some way to make a list of all the .h files in the \winapi\include folder.  For this I did a quick and dirty project called Make_All_Hdr  (project attached) which read the include folder and wrote a header file listing all the .h files.  This drops a file named AllHeaders.h into the flash drive's root folder (copy attached). I then moved it to the \WinAPI folder.
 
Ok so now I've got a header that includes all headers... crash dummy level coding!
 
Next I wrote a quicky Hello World program (project attached) set the project folders to point to the WinApi\Include and WinApi\Lib32 folders on the flash drive and let her rip...The goal is to get it to compile without errors or warnings with all those headers included. 
 
By the way when you run this, stand back... it's pretty amazing!
 
Ok, so now I have a test bed...
 
« Last Edit: April 03, 2014, 04:29:40 AM by CommonTater »

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1572
Re: Using MS standard headers on PellesC
« Reply #27 on: April 03, 2014, 09:47:23 AM »
Hi Tater Welcome back  :D
I'm happy to see you back here, and to see a voluteer that starts to do...  ;D
While I don't agree on some points, easy to speak of and almost impraticable, I see many good points. The most valuable is to strip off debugging informations from libraries that are in the new MS formats and alien tol PellesC.

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  :P
Well, not so advanced. For example: It's not possible to write a Media Player in Pelles C without resorting to MCI which will eventually be removed by MS.
Quote
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...  :o
And more importantly, he knows what has to be done to convert the API for compatibility with his compiler and this information is not available anywhere.
The SDK is not distributable by legal issue, the use license from MS clearly specify this. For a novice to install separate headers would be not an easy job so many many potential users will renounce to PellesC as a C programming training tool.
If you program something enough advanced you should be able to deal with advanced issues, so I don't see the point.
The fact that PellesC works happily with untouched MS headers contraddict the point that it requires twickings to make headers compatible with PellesC compiler and reinforces my affirmation above.

BUT... and this is crucial... What we should really should want to do is use Pelles CRT and extension libs with the Windows API headers.  We should see his distribution of Pelles C as one thing and the Windows API headers and libs as something separate.  It's not enough to get it working with all MS headers including their CRT... we actually do need to convert the headers to work with Pelles CRT as we go. This might mean changing some variable types, modifying typedefs and so on.  It's not a simple matter of changing folders in the project settings.
The compiler itself is not implied in how subsystems and libraries works, the C language compilers works for almost whole systems existing on the earth just changing definitions (headers) and libraries (if it generates code for the right CPU of course ).
The issue in the MS world is that Ms added a lot of stuff not C-standard compliant, and on this PElle made an excellent work adding almost all of them (infact the system compiles executables with MS headers and libraries). But PellesC is also a strict C99, C11 compliant which is divergent from MSVC, so the CRT mainly will have problems (why don't use the free MSVC to compile is this case? )

The big bugaboo with this right now is that most people are probably sitting back waiting to see how badly this fails before getting involved... and of course that is what will cause the ultimate failure.
Very nice ...  ;D
Why should we waste time then? It works for me and I was able to do it, but while it took me a couple of hours to make it work, I had to spend much more time to write documentation and support, that was a kind of due to share the work with others after I have made public the first step ...  :P

Quote
Ok so now I've got a header that includes all headers... crash dummy level coding!
 
Next I wrote a quicky Hello World program (project attached) set the project folders to point to the WinApi\Include and WinApi\Lib32 folders on the flash drive and let her rip...The goal is to get it to compile without errors or warnings with all those headers included. 
 
By the way when you run this, stand back... it's pretty amazing!
 
Ok, so now I have a test bed...
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...)
« Last Edit: April 03, 2014, 11:25:06 AM by frankie »

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 1555
Re: Using MS standard headers on PellesC
« Reply #28 on: April 03, 2014, 02:49:00 PM »
wincodec.h needs fixing ?
intsafe.h(8546): error #1050: Redefinition of macro 'LOWORD'.
intsafe.h(8547): error #1050: Redefinition of macro 'HIWORD'.
May the source be with you

CommonTater

  • Guest
Re: Using MS standard headers on PellesC
« Reply #29 on: April 03, 2014, 03:28:00 PM »
The SDK is not distributable by legal issue, the use license from MS clearly specify this. For a novice to install separate headers would be not an easy job so many many potential users will renounce to PellesC as a C programming training tool.

Yet, oddly enough that's what's happening right now. 
 
Based on experience in other forums, here's how it goes for most people... They will get curious about programming and will go out on the net looking for a free "thingy" to experiment with and will find Pelles C. Many will download a book or a string of tutorials and do some console mode programming (still the best way to learn). Then one of two things happens; either they give up or they hit the limits of Pelles C and they will end up with Visual Studio Express or one of the many MinGW implementations... at that point we lose them.
 
But we do more than simply losing them... because of the limitations of free VC++ and MinGW setups (No IDE, no resource tools, etc) they will usually end up using WxWidgets, QT or some other massively bloated library that ultimately produces really terrible software. The whole industry looses.
 
Quote
If you program something enough advanced you should be able to deal with advanced issues, so I don't see the point.

Ok, lets try this on for size... Some time ago, before coming to Pelles C, I wrote a very comprehensive Inventory Control program in Turbo Pascal. I wrote a custom data base, all the user interfaces, automated tasks such as purchasing and invoicing and even included self-maintenance. When Borland ditched Pascal for Delphi, my project --by then a wage earner-- was orphaned. So I took the decision to rewrite in Pelles C and convert it to a multi-tasking Windows program at the same time. Nearly half a million lines of code, no small challenge, to be sure.  The package has since been sold to another programmer (for a very nice lump of change, I might add) who is now working feverishly to convert it to MinGW.
 
I would say that qualifies me as sufficiently advanced.  In all that, I've tried over and over again to get the MS Headers and Libs working with Pelles C... and it ain't happening. 
 
Quote
The fact that PellesC works happily with untouched MS headers contraddict the point that it requires twickings to make headers compatible with PellesC compiler and reinforces my affirmation above.

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.
 
Try this in a serious project like a media player or desktop enhancement where you need COM objects or try writing your own IDE. You will very rapidly hit the wall... Yet, I can use C-99 standards with TDM-GCC and write these things easily enough... Because the headers are converted to work with that compiler. 
 
Pelles C is most decidedly a beginners tool, always has been.
 
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.
 
Quote
Why should we waste time then? It works for me and I was able to do it, but while it took me a couple of hours to make it work, I had to spend much more time to write documentation and support, that was a kind of due to share the work with others after I have made public the first step ...  :P

Perhaps one rason to waste the time is that at the end of it everybody, including you ends up with a far better compiler/library and API.
 
 
Quote
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...)

But you said we can... You've been insisting that Pelles C works with untouched headers...
 
I proved it does not. 

The question is... what to do about it.

 
 
« Last Edit: April 03, 2014, 03:33:21 PM by CommonTater »