Is Pelles C a dead fish?

[CommonTater]

I have been using MinGWTDM64 with my fork of Bcx (bc9) with excellent results. Just a change from -m32 to -m64
to compile the same source. I am using both gcc and g++ depending on what I am developing.
bc9 is compiled with PellesC7R but the later Bcx releases are compiled with Pelles6. There is a bug report here
somewhere of issues that were never addressed.

I remember that discussion ... optimizer problems ... and it's not the only one.  For someone who's just hacking round at C learning a little, writing some fun programs, unresolved bugs are a minor annoyance but for someone doing serious bevelopment --even comercial work-- these things can be flaming disasters.  As I previously noted other compiler writers are also somewhat unapproachable but bugs in their code do eventually get addressed. 

I will give MingwTDM64 a fair try but from past experience with GCC ports, I'm not exactly enthusiastic about it. 
 
The real question still is whether it's worth trying to support (and revive?) Pelles C or not...
 
The problem is that I LIKE Pelles C.  From my first day using it, I was won over by the comparitive ease with which I could do things.  The Resource Editor is amazing as is the Debugger... Truth be told, I came for a free compiler but stayed for the IDE...

[Stefan Pendl]

I've never had any problems working GUI setups in pure C and WinAPI...
The UI for ultra defrag isn't that complex so forgive me but I don't see the problem.

Sure it can be done, but the amount of code is relative huge.

You need to support DPI, resizing, i18n, etc. today, so this gets all really complex for a dynamically created GUI.

In addition supporting NT4 up to Win8 adds to the complexity too, since the Windows API has quite some changes.

[migf1]

Merry Xmas & Happy New Year everyone!

FWIW, C looks quite strong according to the TIOBE index: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
It keeps leading the chart for the last 2-3 months, if my memory serves me well, while it has never left the top-4 or top-5 over the past decades.

IMHO, a great merit for that accomplishment is due to the embedded systems and the open source Unix & Unix-like communities. Leaving embedded systems out, due to their explicit nature (non-compliance to any standard is pretty much the norm in embedded systems ), Pelles-C never showed an interest in supporting or even partially adopting to anything else than Windows.

Microsoft has decided long ago to abandon C as the primary lang for Win development, in favor of C++ which is still well supported, along side to .net (VS 2012 implements most or all C++11 features, if I remember correctly).
Again imho, .net was Microsoft's "response" to the huge success of Java, in an effort to jump on the train and possibly take over the driver's seat as soon as possible. Their main focus for many years now aims to .net, which has become no doubt a really successful platform among both hobbyists and professionals, although Java keeps its big picture leadership I think (being open source, supported -for a while - by Google with Android, etc). Rumors (or even facts) have it that Win8 returns to native C/C++ dev, but that remains to be seen.

All these most certainly had (and still have) a huge impact on Pelles C's (not so) well being, always imho. It's quite difficult for a professional or even a serious hobbyist to invest on a C tool-chain that is so tightly bound to a platform, whose creators have abandoned the C language altogether.

See the mingw toolchain for example. It is the only C tool-chain widely accepted on Windows, next to VC. Why Mingw and not Pelles C? Well, imho, because of two things:

1. it is open source
2. it happily marries the two most popular worlds *nix/Linux and Windows

The first one makes it easier to keep the tool-chain up to date (since it is not an one-man project), while the second makes it easy to write cross-platform code, or at the very least it makes it much more easy to port your code, compared to Pelles C.

As it stands right now, Pelles C looks like it has to directly "compete" with VS. A really tough battle (actually a never-win one), even with MS having abandoned C to C90 (with some C99 extensions). There's simply no way for an one man project to compete against any MS project, especially on MS's home platform.

Most people would happily prefer VS's handicapped C compiler over the more advanced of Pelles C, because just for the VS IDE alone. There's simply no comparison between the functionality of VS IDE & debugger compared not only to Pelles C's, but almost to any other IDE on any platform. It really cuts down production time (even in C).

Mingw on the other hand, does not compete with MS. It rather uses MS runtime for providing the Windows developers a much more wider concept: cross-platform-ability. For example Mingw makes it much more simple than Pelles C (and VS) to code your application's interface with a cross-platform GUI. It actually opens widely a *nix/Linux door to Windows developers.

It is not by chance that so many crossplatform IDE's are bundled with the mingw tool-chain in their Windows version. And of course it is not by chance that Mingw has easily overshadowed Pelles-C, and in some cases even VS. Take a look for example on how many different projects are "natively" supported by Code::Blocks, using the mingw tool-chain.

At the end of the day, it comes down to Open vs Closed, and unless the latter is backed up by a serious company it stands very few chances to prevail.

Btw, comparing GCC with Pelles C (or even VS) is somewhat like comparing a convenient store at our neighborhood with a multi-national branded super-market. GCC supports almost EVERY computer platform known to man. The overhead is more than justified compared to the big picture benefits.

All that being said, I certainly do NOT think that C is dying. Actually is the only language I know of that has been always in usage since its birth, 3 decades ago, and I really don't see how and why this will stop happening in the near future. It's not the norm of course, and probably it will never be again, but that's quite different from "death".

Pelles C on the other hand, I honestly believe that it needs a different target group in order to be taken as a serious development tool. Embracing non-Windows C standards too (like POSIX for example) along with built-in support for cross-platform frameworks (like GTK+, OpenGL/GFLW/FreeGLUT, etc) would be a step towards the right direction I think. However, something like that might be too much of a task for just one person.

[CommonTater]

Hi Migf1 ...  sorry for the delay, had to give your comments some thought first

I certainly hope the language itself is not dying.  C is a simple language that does amazing things. 

I can't agree that diversifying to other platforms is necessarily Pelle's best course here.  I've never been much for the "cross-platform" way of thinking.  There are many platform specific things that don't get used on strength of "compatibility" or "standards" and the general result is most often mediocre software that doesn't necessarily do a good job of anything.  I would much rather have a truly efficient and capable Windows-only compiler than some milquetoast universal compiler. 

That said, I do see the value in (first) fleshing out the rest of the Windows API and (second) loading up third party libraries so these things are available to programmers. As already noted, Pelle has given us an excellent starting point and I've been able to write a substantial amount of software in Pelles C, over the years. What is missing is any kind of user contribution to the project.  It's like everyone is waiting for Pelle (one guy, working on his own, in his spare time) to do the rest of it for us... And I rather suspect it ain't gonna happen.
 
If you want to see Pelles C support this or that magical new thing, do the work and make it happen then share your results.  Seriously, it's very unlikely to happen any other way.
 
I've shared a number of my personal use libraries over the years hoping to see others do the same and it just doesn't happen.
 
So lets ask the question: "Why do we think it is only Pelle who can do development work on the product?"

[migf1]

Hi Migf1 ...  sorry for the delay, had to give your comments some thought first

No worries, there was no rush anyway

...
So lets ask the question: "Why do we think it is only Pelle who can do development work on the product?"

For me it's because the 2 things I listed in my previous post:
1. It is closed source
2. It is tightly bounded to a platform that a) has abandoned C altogether and b) offers an awesome competitive IDE which even on its free version (Express) is way too functional than Pelles C, despite using an ancient dialect of C.

C is rarely used (if any at all) for Windows development since long (long) time, but it is still the norm in the Open Source *Unix/Unix-like community.

Here's the (non) motivation you are asking for, imho

I for one could contribute once in a while with code that is not Pelles-C/Windows specific, but it compiles with Pelles-C. However, I find no point in posting it in (this) a forum that focuses only to Pelles-C & Windows specifics. This platform has moved on to other languages. I like C very much and I do toy-code only in C in my spare time. However, I surely prefer my toy-code not only being able to run on as many platforms as possible, but mostly I prefer my code having a lot more chances to prove useful to as many other people as possible.

Those things unfortunately have never been met by Pelles C. I've heavily advertised it since v3 if I recall correctly, I've even translated its interface for the last couple of versions, but I could no longer recommend it for anything else than a retro introduction to Win32 programming with C. Frankly, I could only recommend it mostly because it supports decently the C99/C11, otherwise VC Express would my very first recommendation, without even second thoughts.

MinGW meets my needs perfectly though, because it gives me access to a vivid and very much alive C world, and that's why I toy-code in mingw and I only test for compatibility on Pelles-C. That's another reason why I channel my toy-code through my personal website or other forums, instead of this one.

I don't mean anything bad, I just feel that it won't interest anyone here, since everybody in the forum is absolutely focused to Windows specifics. CC HexView for example compiles fine with Pelles-C (except a thing I've reported as a bug, alas in vain) but I really doubt it will interest anyone in the forum, since it only uses standard ISO C99 and only runs on the console (although it does compile "as is" on a variety of platforms using essentially the same piece of code).

Likewise, if I was ever keen to add a GUI to CC HexView, most certainly I would do it using GTK+ (for the reasons I mentioned above), which once again leaves me no room for preferring doing it with Pelles C instead of mingw.

[Stefan Pendl]

offers an awesome competitive IDE which even on its free version (Express) is way too functional than Pelles C, despite using an ancient dialect of C.

Comparing VS Express with Pelles C is not as strait as it seems, since VS Express doesn't support compiling 64-bit executables from within the IDE.
In addition one must install the Windows SDK to be able to compile VS Express projects on the command line for 64-bit.

Starting with the Windows 8 SDK the compilers are no longer included either, so one must buy VS to build 64-bit executables, which is nonsense in a world that heads into the 64-bit direction.

The project I am involved with (see signature) is written in pure ANSI C and supports Windows NT starting with NT4 on all platforms (x86, AMD64 and IA64) using the compilers included with the Windows 7.1 SDK.

If Pelles C would support using the Windows SDK headers and libraries without modification and allow compiling for IA64, there would be no need to use the SDK compilers for us.

I have never had the time and energy to wrap my head around C++, but due to my Commodore 64 BASIC background I am able to at least get something with VB.NET, which I need for work where I customize the CAD package used.

I think that we are currently heading into a direction where we need to learn more than one language to survive.

[aardvajk]

Comparing VS Express with Pelles C is not as strait as it seems, since VS Express doesn't support compiling 64-bit executables from within the IDE.
In addition one must install the Windows SDK to be able to compile VS Express projects on the command line for 64-bit.

Starting with the Windows 8 SDK the compilers are no longer included either, so one must buy VS to build 64-bit executables, which is nonsense in a world that heads into the 64-bit direction.

Your information is out of date. The XP targetting tools mentioned in that entry have now also being released. It doesn't have IA-64 compilers, but not even Intel are using that platform nowadays.

[TimoVJL]

Comparing VS Express with Pelles C is not as strait as it seems, since VS Express doesn't support compiling 64-bit executables from within the IDE.
In addition one must install the Windows SDK to be able to compile VS Express projects on the command line for 64-bit.

You can add 64-bit compiler/debugger to VS Express (2008) and use those from IDE.

[Bitbeisser]

It doesn't have IA-64 compilers, but not even Intel are using that platform nowadays.

I think Stefan was trying to refer here to "Intel/AMD 64", not to the 64-bit "Itanium" architecure...
And Intel sticks quite well with Itanium, specially after Oracle got a kick in the nuts in court in terms of supporting it's database for HP's Itanium based servers...

Ralf

[CommonTater]

For me it's because the 2 things I listed in my previous post:
1. It is closed source
2. It is tightly bounded to a platform that a) has abandoned C altogether and b) offers an awesome competitive IDE which even on its free version (Express) is way too functional than Pelles C, despite using an ancient dialect of C.

Open/Closed source is meaningless here... What's to stop somone from taking (say) DirectX and converting it for Pelles C then making that available.  Just because we don't have the compiler source code does not mean we can't support it.

I will grant that "multi-platform" is the current big buzzword but really... A better string library (and yes I looked at your site) is a better string library... if it runs on Pelles C, then why not contribute it in support of Pelles work?

Oh, btw... tried writing a resource file on VSExpress lately?  POIDE has a full set of resource editors built in... VS?  Not at all.

For the point about broad user bases... pheh... I would rather solve 1 person's problem than offer half a solution to millions.

[CommonTater]

If Pelles C would support using the Windows SDK headers and libraries without modification and allow compiling for IA64, there would be no need to use the SDK compilers for us.

10 points for that!  YES, I would love to see it work with unmodified headers from the SDK....

Either that or lets see if we can't get a group effort going to finish the conversions...

[migf1]

Open/Closed source is meaningless here... What's to stop somone from taking (say) DirectX and converting it for Pelles C then making that available.  Just because we don't have the compiler source code does not mean we can't support it.

I was referring mostly to helping Pelles-C in supporting more standards, like Posix for example.

I will grant that "multi-platform" is the current big buzzword but really... A better string library (and yes I looked at your site) is a better string library... if it runs on Pelles C, then why not contribute it in support of Pelles work?

Thanks for looking at my site, although is not up to date. For example, I'm still working on that string library now and then, whenever I feel like it, although it is not worth it that much right now, being single-byte... nevertheless, I'll take your advice and post it in the forum as soon as I finish some stuff I'm adding to it... here's the unpublished docs I'm writing along with the new additions: http://x-karagiannis.gr/prg/custom/doc/libs/html/modules.html... I want to finish up the single-byte functions, then add multi-byte & wchar_t functions... it will take some time. If that goes well, I may try adding unmanaged (or partially managed) UTF-8 aware functions too.

The thing is that they are not Pelles-C specific stuff, they are x-platform C specific stuff (here is another unpublished one... docs: http://x-karagiannis.gr/prg/custom/doc/con_color/html/, d/l: https://www.box.com/s/vskpxjwb0p3vlb1ymr5q)

Oh, btw... tried writing a resource file on VSExpress lately?  POIDE has a full set of resource editors built in... VS?  Not at all.

Yeap that's a valid point, which only affects the Express editions (the full editions include a resource editor). However, the Express editions let you configure and use from within the IDE any external resource editor, here are a couple I've worked with in the past: a) http://www.resedit.net/ b) http://melander.dk/reseditor#comments and here is a more descriptive article on how to do it (it recommends a different, and rather old, res-editor): http://suite101.com/article/vc-express-external-res-editor-a21264

For the point about broad user bases... pheh... I would rather solve 1 person's problem than offer half a solution to millions.

I don't quite follow you on this one.  I mean, what's wrong with solving problems for millions (or at least helping if not solved)?

In any case, my main point still is that C is not used for Windows development any more, since a long long time. This has made Pelles C and outdated tool, which imho answers your original question

PS. VS Express making it inconvenient to produce x64 binaries is another valid point, which I missed. The major problem though, always imho, is that C is not used for Windows development nowadays.

[Bitbeisser]

In any case, my main point still is that C is not used for Windows development any more, since a long long time. This has made Pelles C and outdated tool, which imho answers your original question

Sorry, but I don't see it that way.
You/we are rather dealing with a "Catch 22"/"Chicken and egg" situation here. One general reason why there is no/little development for Windows in plain C is that Pelle's C is pretty much the only development environment for plain C. All other stuff that is around (like VS Express for example, referring to products in the same "price range" here  ) is based on C++/C# or other .CRAP related stuff...
And too many people are far too lazy today and rather take the easy route (or so it seems to them) and do rather not use plain C.
Would Pelle's C make it easier to access all the constantly updated headers for all the latest Windows and associated fluff, there could be also far more "Windows development in C".

Ralf

[Bitbeisser]

I can't agree that diversifying to other platforms is necessarily Pelle's best course here.  I've never been much for the "cross-platform" way of thinking.  There are many platform specific things that don't get used on strength of "compatibility" or "standards" and the general result is most often mediocre software that doesn't necessarily do a good job of anything.  I would much rather have a truly efficient and capable Windows-only compiler than some milquetoast universal compiler.

Well,...
I personally have the need for a true cross platform development tool (Windows-Linux-Mac OS X, with a dose of Android and iOS on the side), that's one of the reasons why I do not much of my more professional development in Pelle's C, rather use Delphi/Lazarus here instead (the later is by now doing quite a nice job for +95% of all the code/functionality).

But for a lot of people Pelle's C might not be very attractive for a somewhat limited selection even in Windows as it is right now. As I mentioned, one possible way to make it more attractive as a (Windows based) tool in general, would be to build on what's basically already there (the ARM code generator), just switch from Windows CE as the target (which is for all practical purposes dead these days) to (cross-)developing for the Raspberry Pi instead...

So lets ask the question: "Why do we think it is only Pelle who can do development work on the product?"

Well, that depends highly on how you define "work on the product". Adapting 3rd party libraries, certainly this is something that someone other than Pelle can do. But that leaves us still with obvious bugs or anything else that needs some fix/extension to the "inner workings" of the compiler and IDE itself...

Ralf

[CommonTater]

I was referring mostly to helping Pelles-C in supporting more standards, like Posix for example.

I think you're missing the point... You see, we don't want that.  Even Pelle has said so in past conversations.

...nevertheless, I'll take your advice and post it in the forum as soon as I finish some stuff I'm adding to it... The thing is that they are not Pelles-C specific stuff, they are x-platform C specific stuff

Yes... And? ? ?

I don't quite follow you on this one.  I mean, what's wrong with solving problems for millions (or at least helping if not solved)?

Yet there's no motivation to do that here?  Odd...

In any case, my main point still is that C is not used for Windows development any more, since a long long time. This has made Pelles C and outdated tool, which imho answers your original question

Well, yes, it gives me your answer... now we'll have to see if there's a concensus.