Is Pelles C a dead fish?

[CommonTater]

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

Translating headers, adapting libraries, writing original code, whatever.  I am guessing, of course, but it does occur to me that the lack of support could well be a direct result of the lack of support...

[Bitbeisser]

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

Translating headers, adapting libraries, writing original code, whatever.  I am guessing, of course, but it does occur to me that the lack of support could well be a direct result of the lack of support...

Well, I think I mentioned the "Catch 22"/"Chicken and egg" problem in one of my previous posts... 

Ralf

[CommonTater]

Well, I think I mentioned the "Catch 22"/"Chicken and egg" problem in one of my previous posts... 

So you can take my comment as "By way of agreement..."

[migf1]

Sorry, but I don't see it that way.

That's quite healthy, we are just sharing our thoughts

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

Well, I wouldn't say that Pelles C is the only development environment for plain C on Windows. Mingw combined with really powerful free IDEs, like Code::Blocks, Netbeans, Eclipse, and others are perfectly valid choices too, having their own pros & cons compared to Pelles C and/or VS Exp.

I would even dare to say that those IDEs are in par with VS (that is, way too advanced compared to Pelles C's) with the added advantage that they follow the language progress regarding the standards (through mingw, since that's what most of them bundle with, or recommend). Also, most of them are compiler independent, so you can even choose the MS compiler instead of mingw's, provided the Win SDK is installed, and you can even directly import VS projects.. or you can use the Pelles-C compiler instead).

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

Personally I wouldn't blame the developers as being lazy and not using C for Windows development. Imho, it's more due to the strategical decision of Microsoft to ditch C for that task, and promote other languages/frameworks which are now widely accepted (forced or not, it doesn't really matter for this discussion). Those other languages/frameworks are getting far more superior support from MS (and friends) and they also happen to cut production time even more than the half, compared to the abandoned (by MS) C. Both being crucial factors when choosing your development tools as a developer, especially as a professional developer, or even as an above average hobbyist.

For example, he have already mentioned that VS Exp does not provide a resource editor, but it does provide WFA and WPF editors, for C++ and .net langs, respectively. A pretty clear hint coming right from the horse's mouth, no?

[migf1]

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.

I thought the point was your question in the 1st post: "So, lets ask ... Is Pelles C a dead fish, or is it worth supporting?", no?
If yes, the I think my expressed opinion across several posts regarding that question qualifies perfectly as spot on.

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

Don't get me wrong, it's not that I don't want to. It is just that I haven't seen anything like that posted in the Contributions subforum for the past 4-5 years. Everything posted is PellesC/Windows specific, so I thought I would be completely out of place by posting stuff that do not fall into that category.

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.

We're just expressing our thought here, there's no need for one to be right or wrong. It could be that more than opinions are right )or worng), or they could just be smaller factors formulating a more general stand.

[CommonTater]

Don't get me wrong, it's not that I don't want to. It is just that I haven't seen anything like that posted in the Contributions subforum for the past 4-5 years. Everything posted is PellesC/Windows specific, so I thought I would be completely out of place by posting stuff that do not fall into that category.

Which, in my opinion, is the problem itself... "Nobody else is doing it so why should I bother?" .... Perhaps you should bother because nobody else is doing it.  Take a look at my File Associations library, then the Registry Tools library, Then the Easy Splitter custom control... From others you will find ports of OpenGL, SDL, SQLite etc... none of which are Pelles C specific, all of which are from the past few months.  There is some contribution going on, but obviously it's not an active  community effort.

What's genuinely missing is the Fixups for the missing Windows API stuff... As I've said earlier in this thread.

I'm not discounting your thoughts --in point of fact, you may be right-- but there are a couple of flaws in your logic...

For example, it does not logically follow that because Microsoft stopped using C, we have to... They don't use Pasal anymore either but that doesn't stop the Free Pascal crowd.  They've never used D and that bunch are right on the game.  Very little happens in ASM at Microsoft but MASM is alive and well.  The same can be said for ADA, BASIC, and a host of others.  Nothing says we have to use their programming language (although, I will agree that when using their headers, it is easer)

As I said, you may well have put your finger on the problem... but for the wrong reasons... It's not necessarily related to what Programming languages MS is using.  But the obvious lack of support for Pelles C might be related to common perceptions such as those you've conveyed.

Of course there are other reasons as well... Bugs that don't get fixed.  Pelle being somwhat unresponsive. Incomplete header sets.  etc. 

I guess my whole point is that if this is something we can fix on our own, why shouldn't we?  Pelle has written a relatively high quality compiler, assembler and linker, certainly able to stand it's own beside MinGW and VC++ for pure C coding, and the IDE is first rate.  I just don't get why it appears for all the world to have less than a dozen users...

[Bitbeisser]

Well, I wouldn't say that Pelles C is the only development environment for plain C on Windows. Mingw combined with really powerful free IDEs, like Code::Blocks, Netbeans, Eclipse, and others are perfectly valid choices too, having their own pros & cons compared to Pelles C and/or VS Exp.

Sorry, but those are based on C++ compilers (which just happen to compile plain C, in most cases), and have also their heritage in the GNU/*ix world.
There isn't another straight C compiler out there (ok, lcc, which Pelle's C in based on in the past) for Windows...

Ralf

[CommonTater]

Well, I wouldn't say that Pelles C is the only development environment for plain C on Windows. Mingw combined with really powerful free IDEs, like Code::Blocks, Netbeans, Eclipse, and others are perfectly valid choices too, having their own pros & cons compared to Pelles C and/or VS Exp.

Sorry, but those are based on C++ compilers (which just happen to compile plain C, in most cases), and have also their heritage in the GNU/*ix world.
There isn't another straight C compiler out there (ok, lcc, which Pelle's C in based on in the past) for Windows...

Actually, MINGW can be forced to c-99 compliance with a flag in it's command line.
Also don't forget Tiny C, LCCWin and a few others.

But, yes, I agree, Pelles C is the only serious attempt at a Windows/WinAPI development system in standard C... which is one of the reasons I don't want to see it die.

[Bitbeisser]

Well, I wouldn't say that Pelles C is the only development environment for plain C on Windows. Mingw combined with really powerful free IDEs, like Code::Blocks, Netbeans, Eclipse, and others are perfectly valid choices too, having their own pros & cons compared to Pelles C and/or VS Exp.

Sorry, but those are based on C++ compilers (which just happen to compile plain C, in most cases), and have also their heritage in the GNU/*ix world.
There isn't another straight C compiler out there (ok, lcc, which Pelle's C in based on in the past) for Windows...

Actually, MINGW can be forced to c-99 compliance with a flag in it's command line.
Also don't forget Tiny C, LCCWin and a few others.

Ok, I am talking about a compiler with a Windows based IDE...

But, yes, I agree, Pelles C is the only serious attempt at a Windows/WinAPI development system in standard C... which is one of the reasons I don't want to see it die.

Indeed...

Ralf

[frankie]

I think that some points are missed here.
A compiler is a compiler that means a tool able to input a C grammar file and output executable code which executes 1:1 what is described in the source.
Based on this any compiler can produce code suitable for applications even for different target (see my sample OS with cross compiler using PellesC http://forum.pellesc.de/index.php?topic=443.0).
Of course MS has introduced a lot of 'extensions' to the language, but they are almost all implemented in PellesC.
So first point: you don't need access to compiler code to import libraries, or modify or extend existing ones, to the compiling environment. That simply requires some advanced knowledge and OS familiarity. And of course a lot of time  (that unfortunately I really miss in the last times).
MS is not moving away from C simply because there is no other language so efficient, low light and flexible as C to program fast and superior system code.
The real point is that with other languages they can supply user programming interfaces that already contains almost whatever function you want. This way some are happy because even if they are not so bright can show the "hello world" window with a couple of clicks and get proud of theyr knowledge of IS (have you noted that most of the people that carry the last model of smartphone and talk, talk, talk, talk about computers generally barely knows what a keyboar is for...  ).
On the other hand professional users get advantages from fast project deployment and ready tested code (even if with MS you cannot bet on this......).
For this reason MS expose only the interfaces for that languages, even if the core of the code is still in C (maybe not true for WEB tools because thy run on your browser, and a slow system is a good leverage to make you buy a new computer or a new OS....  ).
Sometimes the API's are just wrappers for other languages, sometimes that functions can be reproduced using low level API's.
A the end if you write something 'reusable' don't care about the compiler, one or the other, unless a really broken one, will work.... 

[CommonTater]

So first point: you don't need access to compiler code to import libraries, or modify or extend existing ones, to the compiling environment.

Exactly ....
 

MS is not moving away from C simply because there is no other language so efficient, low light and flexible as C to program fast and superior system code.

Case in point ... drivers; mostly written in C or ASM.
 

A the end if you write something 'reusable' don't care about the compiler, one or the other, unless a really broken one, will work.... 

Yep... the major differences are in linking ... where the linker has to create an OS compatible executable file.
 
( By way of agreement, of course.)
 

[Stefan Pendl]

I think Stefan was trying to refer here to "Intel/AMD 64", not to the 64-bit "Itanium" architecture...

Hi Ralf,

I was referring to the Itanium architecture, even if this is now only used for Servers and there is only a Windows Server Edition available.

Sure it is seldom used and the hardware vendors are no longer producing workstations, but there are still quite some downloads of the IA64 release of UltraDefrag.

We wanted to retire NT4 and Win2k support, but users complained about it.
Due to dropping it initially, adding the compatibility back in resulted in much less code compared to the previous release.

[Bitbeisser]

I think Stefan was trying to refer here to "Intel/AMD 64", not to the 64-bit "Itanium" architecture...

Hi Ralf,

I was referring to the Itanium architecture, even if this is now only used for Servers and there is only a Windows Server Edition available.

Sure it is seldom used and the hardware vendors are no longer producing workstations, but there are still quite some downloads of the IA64 release of UltraDefrag.

Ei verbibbscht! 

Ralf

[frankie]

MS is not moving away from C simply because there is no other language so efficient, low light and flexible as C to program fast and superior system code.

Case in point ... drivers; mostly written in C or ASM.

Yes Tater, but writing in ASM has a couple of drawbacks: I requires much more time to develop and test, is not reusable on different hardware and sw maintenance is a nightmare.
Consider Windows, it could be available for different platform and in different flavours (i.e. WinCE). If it would have been wrote in ASM they have to rewrite everything to move to ARM or ALPHA or POWERPC processors. Normally they write as much as they can in C, then write some small wrappers in ASM to interface the hardware.
In almost all modern OS's, especially in WinNT, this concept is expanded and called Hardware Abstraction Layer (commonly known as HAL). In this case not only the access to the hardware, but even functionalities are abstracted. Think of it like a virtual hardware. In this way lower level routines can be created to access hw resources, or emulate them on platforms that miss a specific function.
To move an OS from one hw platform to another you have to recompile the C code, write some HAL low level code (even for this ASM is limited to hw wrappers), then link and test. 

This is why LINUX can be moved from one HW to another in a couple of days....

[Stefan Pendl]

Ei verbibbscht! 

The world is still turning, so no problem