Pelles C forum
Pelles C => General discussions => Topic started by: LD Blake on March 17, 2014, 07:44:25 PM
-
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.
-
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.
-
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.
-
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. 8) 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.
-
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.
-
Well, I see that idea went over like a lead balloon ....
Later guys!
-
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.
-
This (http://forum.pellesc.de/index.php?topic=5265.0) could be of any help?
-
This (http://forum.pellesc.de/index.php?topic=5265.0) 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.
-
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.
-
I want know what those missing headers are or is this topic just BS :P
-
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++.
-
I want know what those missing headers are or is this topic just BS :P
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 (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.
-
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
/*+@@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 (http://msdn.microsoft.com/en-us/library/windows/desktop/aa383701(v=vs.85).aspx)
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.
-
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 (http://msdn.microsoft.com/en-us/library/windows/desktop/aa383701(v=vs.85).aspx)
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.
-
Little test with WSDK v7.0 and v.7.1
#pragma warn(disable 1058)
#define __STRALIGN_H_
#define WIN32_LEAN_AND_MEAN
#include<windows.h>
#include <commctrl.h>
#include <richedit.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)
{
return 0;
}
Building IncTest_7.exe.
Done.
-
Little test with WSDK v7.0 and v.7.1
#pragma warn(disable 1058)
#define __STRALIGN_H_
#define WIN32_LEAN_AND_MEAN
#include<windows.h>
#include <commctrl.h>
#include <richedit.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)
{
return 0;
}
Building IncTest_7.exe.
Done.
Yep, I can do that too... It works with only the barest skeleton of the API. But try it with out the WIN32_LEAN_AND_MEAN define so it loads in networking and other functionality as well. Things change pretty fast...
-
#pragma warn(disable 1058)
#define __STRALIGN_H_
Tested with WinSDK v7.1 -> works perfect ( apart from the warnings ) ;) :)
Thanks and Cheers
Edit, sample attached ...
-
#pragma warn(disable 1058)
#define __STRALIGN_H_
Tested with WinSDK v7.1 -> works perfect ( apart from the warnings ) ;) :)
Thanks and Cheers
Edit, sample attached ...
Ummmm... sorry to say but it doesn't work. The edit control is not created.
Using the WindowsAPI headers, I get this...
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(898): warning #2195: Unrecognized intrinsic function: '_rotl8'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(899): warning #2195: Unrecognized intrinsic function: '_rotl16'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(900): warning #2195: Unrecognized intrinsic function: '_rotr8'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(901): warning #2195: Unrecognized intrinsic function: '_rotr16'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2609): warning #2195: Unrecognized intrinsic function: '_InterlockedIncrement16'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2610): warning #2195: Unrecognized intrinsic function: '_InterlockedDecrement16'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2611): warning #2195: Unrecognized intrinsic function: '_InterlockedCompareExchange16'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2612): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2613): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2614): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2620): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2621): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2622): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2703): warning #2195: Unrecognized intrinsic function: '_ReadWriteBarrier'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2759): warning #2195: Unrecognized intrinsic function: '__faststorefence'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2765): warning #2195: Unrecognized intrinsic function: '_m_prefetchw'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2811): warning #2195: Unrecognized intrinsic function: '__int2c'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2835): warning #2195: Unrecognized intrinsic function: '__getcallerseflags'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2848): warning #2195: Unrecognized intrinsic function: '__segmentlimit'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2861): warning #2195: Unrecognized intrinsic function: '__readpmc'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2969): warning #2195: Unrecognized intrinsic function: '__mulh'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2970): warning #2195: Unrecognized intrinsic function: '__umulh'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2993): warning #2195: Unrecognized intrinsic function: '__shiftleft128'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(2994): warning #2195: Unrecognized intrinsic function: '__shiftright128'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(3009): warning #2195: Unrecognized intrinsic function: '_mul128'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winnt.h(3022): warning #2195: Unrecognized intrinsic function: '_umul128'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winbase.h(2208): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winbase.h(2209): warning #2195: Unrecognized intrinsic function: '_InterlockedOr'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winbase.h(2210): warning #2195: Unrecognized intrinsic function: '_InterlockedXor'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winbase.h(2218): warning #2195: Unrecognized intrinsic function: '_InterlockedAnd64'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winbase.h(2219): warning #2195: Unrecognized intrinsic function: '_InterlockedOr64'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\winbase.h(2220): warning #2195: Unrecognized intrinsic function: '_InterlockedXor64'.
C:\Program Files\Microsoft SDKs\Windows\v7.0\Include\shellapi.h(666): warning #1063: Single-line comment contains escaped new-line.
Building Peapad.exe.
Done.
These are MS Compiler intrinsics that PellesC does not understand...
One of the hardest lessons to learn... "Compiles" does not mean "Works".
-
Ummmm... sorry to say but it doesn't work. The edit control is not created.
Edit control is created with width 0, height 0.
These are MS Compiler intrinsics that PellesC does not understand...
Do you need those ?
-
Great, another non-answer.
Dear Blake,
First of all I'm not the developer nor the owner of PellesC!
Second I have made something at least, as many others looking at the answers.
Third doesn't seem to you to be a little ... rude?
Do I have to think that you have something personal toward me ?... :o
Last if my work is not of your interest don't worry ;D I'll survive 8) 8) 8)
-
Just as a short information about the base topic (even if the topic starter is again a guest, as usual):
I had contact with Pelle and he is working on version 8.0 at the moment. He has no fixed release date yet, but it is going on.
One new part of the upcoming version: OpenMP 3.1 (see here http://en.wikipedia.org/wiki/OpenMP (http://en.wikipedia.org/wiki/OpenMP))
@frankie: Thanks for your guide, could you open a FAQ-Thread for this?
-
Hi Christian,
Considering that I spent a couple of hours to make it 8), and that this seems a problem that have not been solved in so many years I would collect some feedbacks before to organically put it down.
As first action I'll move it in a different topic to make it more visible.
-
I had contact with Pelle and he is working on version 8.0 at the moment. He has no fixed release date yet, but it is going on.
Very nice to hear that 8)
-
@Frankie: Good idea. Saw the topic.
-
Glad to know Pelles C is still in development. Are there any plans for open-sourcing the code (or some of it)?
-
No, as far as I know there is no plan to make it open source.
-
I had contact with Pelle and he is working on version 8.0 at the moment. He has no fixed release date yet, but it is going on.
This is good to hear.
I really wish Pelle would rejoin us... even if it's only for an hour Saturday Mornings... He is the only person who really knows what's going on under the hood and it would be a big boost for all of us if we could actually speak to him.
As for open sourcing the project ... I vote NO! In my experience open source usually invites a competition with every half-assed coder competing to get his silly new function included. The project soon becomes bloated and eventually unsustainable.
For a very good example of what can happen, take a look at the D programming language... This is a powerful compiler with most of the right ideas. However Digital Mars made the tragic mistake of going Open Source for their RTL, resulting in 2 competing libraries, both loaded to the tilts with stuff nobody will ever use.
That said... I would strongly urge Pelle to find 2 or 3 people he trusts and go to a team approach for the project. This is a huge undertaking, too much for one person to do adequately and sadly it seems to be suffering for it as the toolchain is being updated but ancilliary issues such as outdated Windows API headers and libs continue. Dividing up the work... Perhaps handing the Windows API maintenance off to someone else would surely improve the project by leaps and bounds.
Anyway... I guess you noticed... I'm baaaaack... ::)
-
Got tired of hangin' with President Poutine eh? :o
Welcome back CommonTator. :D
-
Got tired of hangin' with President Poutine eh? :o
? Sorry... I'm not catching the reference...
Welcome back CommonTator. :D
We'll have to see how long my welcome lasts...
As I've said in the other thread, I like Pelles C. IMO it's the best compiler/IDE setup going, at any price. But I will say that some considerable improvement is needed in the Windows API support. This is the difference between PellesC being a contender or a toy... and it's also a wall that I'm honestly quite tired of banging up against. So I'm not here without purpose.
John F has all my addons and libs (with sources) now and they'll stay there no matter what happens. The person who pissed me off so severely is in the ignore list. Others have contacted me privately to ask me to rejoin ... so we'll see what happens.
-
Got tired of hangin' with President Poutine eh? :o
? Sorry... I'm not catching the reference...
It's a word play on your handle, a currently influential person (http://www.themoscowtimes.com/news/article/kiev-man-finds-dog-that-looks-like-putin-photo/486320.html), and this rather tasty dish (http://en.wikipedia.org/wiki/Poutine). I must confess I coveted your Moniker and Avatar and would have stolen it for myself while you were away (abroad?) except that it is uniquely you.
-
It's a word play on your handle, a currently influential person (http://www.themoscowtimes.com/news/article/kiev-man-finds-dog-that-looks-like-putin-photo/486320.html), and this rather tasty dish (http://en.wikipedia.org/wiki/Poutine). I must confess I coveted your Moniker and Avatar and would have stolen it for myself while you were away (abroad?) except that it is uniquely you.
ROFL... Ok, now I get it... It's a little far afield but it is funny.
The handle is actually a play on "commentator" ... someone who writes commentary... which seems very appropriate in a forum setting. I've been using it for a long time now and I'm frankly a little surprised that most people can't make the connection between "ordinary potato" and "writing of messages"....