Updates?

[LD Blake]

Is there any news about when we might see the next version of Pelles C?
 
In particular the API headers and libs are becoming very dated and in need of upgrading.
 
 

[Vortex]

I agree with LD. The import libraries are very easy to create but the most critical part is the header files. They are outdated and MS's SDK header files are extremely complicated.

We hope to see a new version of Pelles C updating the header and library files.

[LD Blake]

We hope to see a new version of Pelles C updating the header and library files.

Or at least some documentation on what is required to do this ourselves.
 

[DMac]

Or at least some documentation on what is required to do this ourselves.

That goes along with my thinking on this.  We could determine which headers need to be converted and then make a list.  Anyone of us, who is willing, then could take on a few headers and convert them.
FWIW Code project has this new workspace functionality that allows some kind of collaboration between developers on projects.  I got invited in -- perhaps because the SimpleGrid I wrote to replace BabyGrid won the November competition.  Unfortunately, being a lone wolf coder I'm not sure what to do with it.
I have in my possesion two coupons that will give two other persons (who are registered with code project and smarter than me) the ability to set up one of these workspaces with the ability to check code in and out.  We perhaps could use that as a place to work on this kind of collaborative project.
If anyone is interested, let me know.

[LD Blake]

That goes along with my thinking on this.  We could determine which headers need to be converted and then make a list.  Anyone of us, who is willing, then could take on a few headers and convert them.

Exactly .... why this has not been an ongoing project is beyond me.  Pelle offers us a nice IDE and Compiler suite.  What he did with Windows API should be considered as a "starting point", not an end product.
 
I'm betting there are several users here, people much smarter than me, who have already converted chunks of the API for their own use... and they're not sharing this because???
 

FWIW Code project has this new workspace functionality that allows some kind of collaboration between developers on projects.

What's wrong with doing it here... Perhaps we could set up a special forum just for "Windows API Updates" and make the whole thing an ongoing project amongst Pelles users.
 
But... what is sorely needed is some kind of documentation on what needs changing and why... and for that Pelle is the best source.  His absense is not helping.
 

[LD Blake]

Well, I see that idea went over like a lead balloon ....
 
Later guys!
 

[Vortex]

We hope to see a new version of Pelles C updating the header and library files.

Or at least some documentation on what is required to do this ourselves.

That's a good idea.

[frankie]

This could be of any help?

[LD Blake]

This could be of any help?

Not much help at all.  But thank you.
 
What we need is bundles of headers and libs people can download and add to their installations, not a 10 year old web article.
 
I would do some of these conversions myself and I've tried with no luck at all. Looking at the Pelles C headers beside the MS headers from the SDK I see large, often bewildering differences.  So we also need documentation to guide us on making the changes.
 
It seems everyone is happy to appear helpful but nobody is willing to do the work.
 
 
 

[frankie]

I meant:

Unfortunately not all ole/com header files are present in PellesC distribution, and many unexperienced programmers that want to experiment in this field are thrown away by the huge number of errors that they get when trying to use standard MS headers taken from SDK's.
One of the opinions that PellesC users realize is that the compiler itself is kind of inconpatible compiler, and that MS headers from SDK's are unusable in PellesC. That's definetly not true. The real reason for all that errors is that MS use many bloating decorations even in header files that are not defined in PellesC standard headers.

What we need is bundles of headers and libs people can download and add to their installations

IMHO what we need is to understand what is incompatible with standard headers and write suitable stubs so we can *directly* use MS SDK's distributions.

It seems everyone is happy to appear helpful but nobody is willing to do the work

Due to to personal lack of time in the last year I can't be very active, but if you start I'll do my best to help.

[TimoVJL]

I want know what those missing headers are or is this topic just BS

[LD Blake]

I meant:
Unfortunately not all ole/com header files are present in PellesC distribution, and many unexperienced programmers that want to experiment in this field are thrown away by the huge number of errors that they get when trying to use standard MS headers taken from SDK's.

Not just ole/com are missing. 
 
The MSSDK ver7.0 has 1915 headers, 351 libs...
Pelles C provides 434 headers and 148 libs. 
 
1481 headers and 286 libs is not a small omission.
 

One of the opinions that PellesC users realize is that the compiler itself is kind of inconpatible compiler, and that MS headers from SDK's are unusable in PellesC. That's definetly not true. The real reason for all that errors is that MS use many bloating decorations even in header files that are not defined in PellesC standard headers.

And those decorations would be? 
Where's the documentation for this? 
How do you justify leaving out entire blocks of Windows functionality on this basis?
 

IMHO what we need is to understand what is incompatible with standard headers and write suitable stubs so we can *directly* use MS SDK's distributions.

Ok, I'll bite, I'll even help ...
What do we need to do?
Where's the documentation?
 

Due to to personal lack of time in the last year I can't be very active, but if you start I'll do my best to help.

My friend, as I've told you before, I have tried many many times to get some of these headers changed over and it just ain't happening for me... Thanks to a total lack of documentation I have no idea what needs to be done or how to go about doing it.
 
Pelles C is a very powerful C compiler and CRT. By all rights it should be one of the most used compilers in the world... but it is woefully crippled by it's incomplete implementation of the Windows API and the years long silence of it's author. 
 
As most here know I've been a fan and a user of Pelles C pretty much since version 2, almost a decade, I've contributed many tools and helpers as well ... but if these issues cannot be resolved, my next project will be written in the C language mode of MinGW or VC++.
 

[LD Blake]

I want know what those missing headers are or is this topic just BS

Not BS ... grab a copy of the MS-SDK for Windows 7 from here...
http://www.microsoft.com/en-ca/download/details.aspx?id=18950
 
This includes a full set of Windows API headers and libs for both 32 and 64 bit compiles.
 
Compare the list from the SDK with the list from Pelles C ... there are 1481 missing headers and 286 missing libs... and this doesn't even include DirectX or any of the other add-on functionalities. 
 
Attached is a copy of the output of windiff, also attached.
 

[frankie]

Dear Blake,
that you are not very happy with Pelle for his latency is evident. That you wrote a lot of code and utilities for this compiler, and many controls that it uses, is clear too.
Anyway

Not just ole/com are missing.

My post was a sample for these headers, but the concept could be extended.

And those decorations would be? 
Where's the documentation for this? 
How do you justify leaving out entire blocks of Windows functionality on this basis?

The decorations are in the header file that I wrote to be prepended to standard headers

Code: [Select]

/*+@@file@@----------------------------------------------------------------*//*!
 \file ComDefPelles.h
 \par Description
            Contains definitions for MS bloating decorations coming from
            IDL compilers.
            Include this file before any MS OLE/COM related header
 \par  Status: --
 \par Project:
            OLE/COM Integration in PellesC
 \date Created  on Sat Mar 30 17:34:56 2013
 \date Modified on Sat Mar 30 17:34:56 2013
 \author Frankie
\*//*-@@file@@----------------------------------------------------------------*/

#ifdef __POCC__
#ifndef __in
#define __in
#endif
#ifndef __deref_out
#define __deref_out
#endif
#ifndef __out_opt
#define __out_opt
#endif
#ifndef __out
#define __out
#endif
#ifndef __out_ecount_opt
#define __out_ecount_opt(x)
#endif
#ifndef __out_ecount
#define __out_ecount
#endif
#ifndef __RPC__in
#define __RPC__in
#endif
#ifndef __RPC__deref_out
#define __RPC__deref_out
#endif
#ifndef __RPC__deref_out_opt
#define __RPC__deref_out_opt
#endif
#ifndef __RPC__out
#define __RPC__out
#endif
#ifndef __RPC__in_ecount_full
#define __RPC__in_ecount_full(x)
#endif
#ifndef __RPC__out_ecount_full
#define __RPC__out_ecount_full(x)
#endif
#ifndef __RPC__in_ecount_full_opt
#define __RPC__in_ecount_full_opt(x)
#endif
#ifndef __RPC__in_range
#define __RPC__in_range(x,y)
#endif
#ifndef __RPC_unique_pointer
#define __RPC_unique_pointer
#endif
#ifndef __RPC__in_opt
#define __RPC__in_opt
#endif
#ifndef __RPC__inout
#define __RPC__inout
#endif
#ifndef __RPC__deref_inout_opt
#define __RPC__deref_inout_opt
#endif
#ifndef __RPC__inout_xcount
#define __RPC__inout_xcount(x)
#endif
#ifndef __RPC__in_xcount
#define __RPC__in_xcount(x)
#endif
#endif
The documentation is Here
Consider if they are really needed or are just a way to wast compiler time.
Now if you want modify standard headers, and continue to change them over and over again each time MS produce new SDK's maybe a choice, but I don't know how much worth considering that the m ost part of them is related to C++ code that PellesC cannot handle.
Have a nice weekend.

[LD Blake]

Dear Blake,
that you are not very happy with Pelle for his latency is evident. That you wrote a lot of code and utilities for this compiler, and many controls that it uses, is clear too.
Anyway

Not just ole/com are missing.

My post was a sample for these headers, but the concept could be extended.

Great, another non-answer.
 

And those decorations would be? 
Where's the documentation for this? 
How do you justify leaving out entire blocks of Windows functionality on this basis?

The decorations are in the header file that I wrote to be prepended to standard headers
The documentation is Here
Consider if they are really needed or are just a way to wast compiler time.

So what do I do with this?  Include it first and the SDK headers will magically work?
 
Also, if it's that easy why isn't this part of the standard Pelles C distribution?
 

Now if you want modify standard headers, and continue to change them over and over again each time MS produce new SDK's maybe a choice

Ok... an example... I recently tangled with the RichEdit control.  Pelles header for this was from Windows 2000 and could not even open the newer versions of the DLL.  I couldn't get the new header working for the life of me, so I ended up loading the DLL and using it's internal registration name.  So yes, sometimes you do have to update the headers. 
 

but I don't know how much worth considering that the m ost part of them is related to C++ code that PellesC cannot handle.

And the list of those headers is where?
 
See... it's not just a number, it's more complex than that... Which headers *can't* be converted?  Which headers are out of date?  and on and on...
 
I'm mostly an applications programmer... I use the Windows API... I don't maintain it.  I'm happy to learn but really, guys, where's the nice clear instructions? 
 
This stuff might be easy for you and these nice little 5 line answers sound helpful... but trust me, unless someone sits down and writes this up as a tutorial "Converting MS-SDK headers to PellesC" most of us aren't going to get the job done on our own.