Pelles C forum
Pelles C => General discussions => Topic started by: CommonTater on December 28, 2012, 03:51:34 PM
-
Sure is quiet around here these days...
In the last while I've been venturing out and reading other programming forums, looking for an active community of C-99 users and Pelles C users in particular. Nada... most everywhere I went, C itself seems to be relegated to a "secondary topic" on C++ forums or even co-mingled with C++ posts, lacking it's own forum. And in all that virtually no mention of Pelles C anywhere.
Back in the CBoard days, the common opinion was that Pelles C is a beginner's tool, fine for learning on but not much good for the serious programmer. Common complaints were that it's "incomplete", missing many of the headers needed to produce commercial quality code... no COM, no DirectX, no DShow, and so on. Another frequent observation I saw is that it's "abandonware", as Pelle himself appears to have lost interest in the project and I am, reluctantly, forced to agree... it does look that way. Then, finally, the thing I noticed least often but most strongly: "People haven't gotten behind the project".
This last thing... not getting behind it... is probably the one thing that's been true since I joined up here. Indeed Pelles C has most everything you need for general application development. But on other programming forums dedicated to a single package I've watched people climb into the project and take it to it's limits.
The D language compiler and forums are a good example, so many people got behind this compiler they ended up with two huge, competing, run time libraries that were 100% written by D users. C++ seems to have garnered even more support as I found huge repositories of C++ libraries and classes on places like SourceForge, etc.
Pelles C is a very capable product that, far as I can see lacks only "the rest" that would come after Pelle gave us a really great starting point. For reasons wholley mysterious, people simply never got behind it and fleshed it out the way they have on so many other projects...
I'm not surprised that Pelle's visits are shorter and further between... From his perspective, his project despite all it's powers must shurely look like a "dead fish" that somehow never caught on.
Now, let me be very clear about this. I'm not writing to chastize anyone; I would probably be the first to deserve it anyway. Rather, I'm hoping to encourage at least a few of us to pick up the reins and support the project by sharing source code, headers and libs, converted libraries... whatever you can give that expands on Pelle's "starting point".
For example: Most of my AddIns are things I actually use for my own projects in Pelles C, either to solve problems or make the job easier. It takes me only a few seconds to zip them up and upload them and then everyone has the chance to try them out for themselves.
So, lets ask ... Is Pelles C a dead fish, or is it worth supporting?
-
Hi Tater! You mentioned that you have visited other programming forums and have noticed yourself that the C programming language appears to be fading away as today's programmers are turning to other languages that are 'cool', 'the newest thing', etc. If I remember correctly, you mentioned in these very forums that MicroSoft itself is moving toward C++ and C# not too long ago.
As you said, (in another topic), today's programmers are becoming more like appliance operators, pasting this piece of code from here and that piece of code from there to form their programs, without really understanding the code and the reason that it was written in the manner that it is. I would even go as far as to say that MicroSoft discourages people from trying to write code, even for fun or experimentation. (Me, I am just a hobbyist. I am not trying to make a living out of programming.) I think it was with the release of either Win98 or Me2000 that MS no longer included QBasic (or any other language for the user) with the OS. Agreed that the OS is much more complex now than it was then. I look in the bookstores and on-line and there are very few books on how to write code; but, plenty on using applications that are already written. It wasn't until a couple of years ago that I came across Petzold's book on using the Windows API.
Anyway, enough of me ranting and raving, Happy New Year,
David E.
-
Well, ... :-\
I certainly I would not call it a dead fish, it doesn't smell like it at least just yet.
One issue that I see is that it is simply a plain C compiler, something that nowadays is considered an "old" language.
Nothing really wrong with that, it is a tried and proven programming language, which actually is still used a lot in professional development.
But it is not an "easy" programming language either, making it hard for beginners to get "the hang of it", specially if they are skipping on learning the (programming language depended) basics of programming in the first place...
But nowadays, a lot of people (specially beginners) are much more drawn to the "new and shiny", like C# or D, which you mentioned. Or things like Python, Ruby, Haskell, Eiffel, Erlang and a lot more fluff, it sometimes seems to be like a race for the "new programming language of the month".
A lot of those seem to have their own issue, So while D seems to be fairly popular (at least there is a lot of rave about it), those two RTL you mentioned are IMHO a huge drawback, as they are widely incompatible with each other and you have to settle on one or the other, with neither one being a "one size fits all"...
The lack of header files for those things that you mentioned are IMHO not a real hurdle for acceptance of people doing more professional stuff, but the somewhat lackluster approach of Pelle to his own project on the other side certainly is.
While for newbie use or even for fun/open source kind of projects it is not such a big deal, if you depend for professional projects on it, it certainly is. In such a case, you simply can't wait for 6-9 month to get a reply about a possible bug report and a fix for that. That certainly hurts the project more than the lack of some header files for some applications...
One thing that I noticed recently while trawling the web is for example that for the Raspberry Pi. that cheap $45 ARM computer, a lot of "retro tools" are all the sudden being ported, like BASIC interpreters and plain old C compilers, which seems to me to indicate that there is some interest in this and not just for the all the new stuff that is buzzing all over the forums.
To me, it would make sense to pick up the Windows CE stuff that Pelle wants to bury, and make development for the ARM based Raspberry Pi a new option, which could attract a lot of renew interest. But without a real interaction of Pelle, well, one can only dream... :'(
Just my 2c,
Ralf
-
Well, ... :-\
I certainly I would not call it a dead fish, it doesn't smell like it at least just yet.
:o
One issue that I see is that it is simply a plain C compiler, something that nowadays is considered an "old" language.
Nothing really wrong with that, it is a tried and proven programming language, which actually is still used a lot in professional development.
This is shaping up to another "End of Pascal" experience for me. Near the end of that I was watching Pascal die a slow and awkward death at the hands of Delphi and it's OOP model. A once sleek and very friendly programming language was being buried in a sea of blubber as objects replaced functions and inch by inch the language was forcefully transformed into something less than useful. I moved to C to get into a language that produced small, reliable and hopefully fast code... I was not disappointed.
Now this happens again. Suddenly I'm feeling C fall out from under me as well. Support is dwindling, C is used only when C++ is too awkward for a given task and worst of all, the only real C package out there appears on the virge of being abandoned.
But it is not an "easy" programming language either, making it hard for beginners to get "the hang of it", specially if they are skipping on learning the (programming language depended) basics of programming in the first place...
As we both agree, this is NOT the way to learn programming... The base concepts, order of execution, loops, functions, etc. that are common to all languages are not something one can simply gloss over. We may disagree on how to learn this, but that's here nor there when you realize that a lot of programmers don't even bother.
But nowadays, a lot of people (specially beginners) are much more drawn to the "new and shiny", like C# or D, which you mentioned. Or things like Python, Ruby, Haskell, Eiffel, Erlang and a lot more fluff, it sometimes seems to be like a race for the "new programming language of the month".
At the risk of quoting Homer Simpson: "OOOOOO Shiiiinnnnyyyy".
A lot of those seem to have their own issue, So while D seems to be fairly popular (at least there is a lot of rave about it), those two RTL you mentioned are IMHO a huge drawback, as they are widely incompatible with each other and you have to settle on one or the other, with neither one being a "one size fits all"...
IMO... Bright's mistake with D was to allow the RTL to be developed without primary guidelines. He just left it up to the Open Source community and got exactly what you should expect when you have too many cooks making the broth. Had he set out some guidlines right up front, it's very likely he'd have a programming language second to none. As it is now, it's being choked out of existence by competing interests and public confusion.
The lack of header files for those things that you mentioned are IMHO not a real hurdle for acceptance of people doing more professional stuff, but the somewhat lackluster approach of Pelle to his own project on the other side certainly is.
Well, I think we have to be fair here... This hasn't always been the case. Up to about version 6, Pelle was very active on these forums and did contribute very strongly to his own project's success. But in more recent times your observation is correct. It's almost like he's gone on to other things and only visits here when the mood hits. His current lack of interest is plenty obvious and yes it is a problem.
While for newbie use or even for fun/open source kind of projects it is not such a big deal, if you depend for professional projects on it, it certainly is. In such a case, you simply can't wait for 6-9 month to get a reply about a possible bug report and a fix for that. That certainly hurts the project more than the lack of some header files for some applications...
Agreed...
While it's not obvious here I do have some very large projects out there, written in Pelles C. In particular, an inventory package specialized for electronic parts, that I ported over from Pascal in 2004 and is still in use in a few companies. There have been times when I made bug reports and got no answers, then ended up with some pretty ugly workarounds...
However; we should also note that Microsoft is even less responsive with VC++ and the GNU team is virtually unreachable when it comes to such things. For reasons I will never fully understand, the most crucial software in the computer industry --languages, compilers, linkers, etc.-- is most often the least supported.
I can't help wondering if I've landed on something here...
Or maybe I just don't want to change languages again.
-
This is shaping up to another "End of Pascal" experience for me. Near the end of that I was watching Pascal die a slow and awkward death at the hands of Delphi and it's OOP model. A once sleek and very friendly programming language was being buried in a sea of blubber as objects replaced functions and inch by inch the language was forcefully transformed into something less than useful.
Sorry, can't absolutely not agree with your here.
Objects (which had been introduced first with Borland Pascal 7, not with Delphi) is more or less "optional". For anything that isn't Windows/thread related, you just don't "have to" use it.
OOP is IMHO a more general issue all together. As with a lot of things in life, used in moderation, it can be quite beneficial. If you overdo it, you can quickly overdose... :P
And you need to know what you are doing in the first place. Otherwise, overly complicated OO structures rather obfuscate your code and make it rather less maintainable, to the contrary what is touted as one of it's benefits...
I moved to C to get into a language that produced small, reliable and hopefully fast code... I was not disappointed.
You could do the very same with Delphi (or FreePascal/Lazarus for that matter). And you can avoid of hassle with all the string (resources) stuff for Windows programming, something for which C IMHO is a bit on the inept side...
I personally have never used C for major "application" development, with the exception for a large CAD system, but that was born and designed in Pascal and kept a certain "Pascalish" appearance even after we switched to using a C compiler instead of the long used and venerable Pascal MT+86.
I always used it for small tools, stuff that worked in the background through scripts or system calls or for administrative purposes. For end user applications, I might have been used to the "comforts" that Pascal and BASIC implementations (yes, BASIC, like in Business BASIC or HP/Rocky Mountain BASIC) provide to concentrate on the application more than on the way to implement them...
Now this happens again. Suddenly I'm feeling C fall out from under me as well. Support is dwindling, C is used only when C++ is too awkward for a given task and worst of all, the only real C package out there appears on the virge of being abandoned.
C just hasn't created a lot of buzz in recent years, simply because a lot of folks seem to fall for those Homer Simpson moments... ;D
IMO... Bright's mistake with D was to allow the RTL to be developed without primary guidelines. He just left it up to the Open Source community and got exactly what you should expect when you have too many cooks making the broth. Had he set out some guidlines right up front, it's very likely he'd have a programming language second to none. As it is now, it's being choked out of existence by competing interests and public confusion.
I think WB had a good idea to tackle what Stroustrup did from a slightly different starting point, fixing some of the early shortcomings that showed up in C++. But I think in any way, with an emergence of a lot of highly hyped languages, it just was an "also ran".
But if you look on what actually used software is written in, none of those "buzz of the day" languages show up...
Well, I think we have to be fair here... This hasn't always been the case. Up to about version 6, Pelle was very active on these forums and did contribute very strongly to his own project's success. But in more recent times your observation is correct. It's almost like he's gone on to other things and only visits here when the mood hits. His current lack of interest is plenty obvious and yes it is a problem.
I found Pelle's C with version 4.5, shortly before 5 was released and I can't say that I have ever seen much of him around here besides some "short bursts" when he felt like releasing a new version and shortly thereafter.
I don't blame him for having higher priorities in his life, but he should consider opening up the development of Pelle's C a bit more, I think there are a few folks around here who could help to make this more appealing through faster updates and enhancements in a team effort...
While it's not obvious here I do have some very large projects out there, written in Pelles C. In particular, an inventory package specialized for electronic parts, that I ported over from Pascal in 2004 and is still in use in a few companies. There have been times when I made bug reports and got no answers, then ended up with some pretty ugly workarounds...
Well, I wouldn't have made that switch if I would have been in your shoes at that time. While maybe not that "shiny", you could have stayed in a more familiar environment and adapted to Delphi, with the opportunity to use FreePascal as an alternative (which is after all around for more than 15 years, I know it back from the days when it was called FPK and produced GO32 applications). IMHO for applications like that, a far more economic approach...
However; we should also note that Microsoft is even less responsive with VC++ and the GNU team is virtually unreachable when it comes to such things. For reasons I will never fully understand, the most crucial software in the computer industry --languages, compilers, linkers, etc.-- is most often the least supported.
The last M$ compiler that I used in anything serious was BASCOM on MS-DOS and for a while their Fortran 5.1 and early PowerStation stuff... :P
I seriously fail to see why they came up with all that .NET fluff and C#/F#/VB.net in the first place (and now apparently slowly go back to C++).
And GCC is (and always has been) a monster that is more of a necessary evil and burden. I get shivers down my spine even thinking about being forced to use it...
I can't help wondering if I've landed on something here...
Or maybe I just don't want to change languages again.
That's up to you, though I would stay and soldier on or "go back to the roots"... ;)
Ralf
-
This is shaping up to another "End of Pascal" experience for me.
Objects (which had been introduced first with Borland Pascal 7, not with Delphi) is more or less "optional". For anything that isn't Windows/thread related, you just don't "have to" use it.
Not entirely true... Under Delphi, which was actually a bunch of junk piled on top of TP7, you had no choice but to use some of the OOP stuff since the compiler linked in a number of classes for error handling and such... Even if you went outside the IDE and worked in notepad with the command line compiler, you ended up with OOP code... The killer was when I wrote an MCI command in Delphi to play a midi file from the command line and the program ended up being over a megabyte... The same program was 16k in C.
OOP is IMHO a more general issue all together. As with a lot of things in life, used in moderation, it can be quite beneficial. If you overdo it, you can quickly overdose... :P
And you need to know what you are doing in the first place. Otherwise, overly complicated OO structures rather obfuscate your code and make it rather less maintainable, to the contrary what is touted as one of it's benefits...
You'll get no argument from me on that one!
I personally have never used C for major "application" development... I always used it for small tools, stuff that worked in the background through scripts or system calls or for administrative purposes.
Except for the lack of a string type (and even Delphi had to translate it's strings for Win-API) the only real advantage to Pascal is it's garbage collector... the rest is pretty much "C with an accent" as one of my students put it.
But if you look on what actually used software is written in, none of those "buzz of the day" languages show up...
Yep... and that's why I've stuck with Pascal then C... 5 years from now, when these Fad Languages start falling away, I don't want to be stuck with a bunch of code I can no longer upgrade.
I found Pelle's C with version 4.5, shortly before 5 was released and I can't say that I have ever seen much of him around here besides some "short bursts" when he felt like releasing a new version and shortly thereafter.
When I first showed up, around ver 2.90, he was very active in the forums. We had some very interesting conversations back then. I even suggested some stuff that ended up being part of the current setup ... like the WIN32_DEFAULT_LIBS and the Message Table Editor.
I don't blame him for having higher priorities in his life, but he should consider opening up the development of Pelle's C a bit more, I think there are a few folks around here who could help to make this more appealing through faster updates and enhancements in a team effort...
Agreed ... if he would take on some help things might be a lot better. I don't know how much help I could be, but I'd be willing to do my part...
Well, I wouldn't have made that switch if I would have been in your shoes at that time. While maybe not that "shiny", you could have stayed in a more familiar environment and adapted to Delphi, with the opportunity to use FreePascal as an alternative (which is after all around for more than 15 years, I know it back from the days when it was called FPK and produced GO32 applications). IMHO for applications like that, a far more economic approach...
In the short term yes, a lot less work... but in the long run I'm glad I did the work, since Pascal actually is a dead fish...
The last M$ compiler that I used in anything serious was BASCOM on MS-DOS and for a while their Fortran 5.1 and early PowerStation stuff... :P
Actually, it's starting to look like I'm going to have to get some kind of setup going with the VC++ compilers from the SDK... they're about the only 32/64 bit compilers that are compatible with the full set of windows headers and libs... (And no, that's not a choice I wanted to make!)
I seriously fail to see why they came up with all that .NET fluff and C#/F#/VB.net in the first place (and now apparently slowly go back to C++).
Beats me ... didn't make any sense at the time, makes even less sense now... "Stupid is as stupid does"...
And GCC is (and always has been) a monster that is more of a necessary evil and burden. I get shivers down my spine even thinking about being forced to use it...
I know... I set up the MinGW and MinGW64 ports of it on my system, took one look at the tangled up mess and ditched them without even trying them out.
That's up to you, though I would stay and soldier on or "go back to the roots"... ;)
Well, I can't really go back to Pascal with the huge amounts of C code I have...
-
I wish I could be more active on the forums but I'm still green to C so besides asking questions that is all I can do for now :'(
I'm not a working programmer .....Learning for myself so not sure how C is still used in the working field BUT I do see more colleges offering C courses
Just signed up myself for an "Intro to C" class at my local community college and last year they did not offer this class (just Intro to java)
-
I wish I could be more active on the forums but I'm still green to C so besides asking questions that is all I can do for now :'(
Your opinions are still valid...
I'm not a working programmer .....Learning for myself so not sure how C is still used in the working field BUT I do see more colleges offering C courses
Just signed up myself for an "Intro to C" class at my local community college and last year they did not offer this class (just Intro to java)
You're probably going to see more of that since people are finally figuring out that Java babysits a programmer too much in the learning phases, producing a bunch of "well trained idiots" who don't actually know anything about memory management, string buffers, memory allocations etc. that are common in both C and C++ (and a whole host of other languages). They're getting the point that you need to know this stuff even if you seldom use it...
Plus, Java is slowly falling to disfavour as more and more people move to C++ ...
Sadly, it looks like C is taking the same hit.
EDIT: Don't underestimate the power of "self-education" ... There is much to be said for learning something because you *want* to learn it, instead of learning it because "the boss wants me to" or "my parents are paying for the course"... if you get my drift.
-
Your opinions are still valid...
;D I will be more active on the forums
You're probably going to see more of that since people are finally figuring out that Java babysits a programmer too much in the learning phases, producing a bunch of "well trained idiots" who don't actually know anything about memory management, string buffers, memory allocations etc. that are common in both C and C++ (and a whole host of other languages). They're getting the point that you need to know this stuff even if you seldom use it...
Plus, Java is slowly falling to disfavour as more and more people move to C++ ...
Sadly, it looks like C is taking the same hit.
EDIT: Don't underestimate the power of "self-education" ... There is much to be said for learning something because you *want* to learn it, instead of learning it because "the boss wants me to" or "my parents are paying for the course"... if you get my drift.
Yes I get your drift ;)
I feel better of myself for learning (the little so far) of C that I have
-
Yes I get your drift ;)
I feel better of myself for learning (the little so far) of C that I have
As we've discussed before, the thing you need to do is knuckle down with the books and "just do it"... I'm sure your course will help, but the real learning usually starts when you decide on your first independent project. I've been pounding Source for quite a while. It's never been my major income but it hasn't hurt me either... 90% of what this old dabbler knows comes from making the mistakes and taking on the challenges... The books were a great start... but that's all they were... a start.
As a friend of mine who teaches music is fond of saying: "School teaches you how to learn. The real education starts when you play your first solo."
As far as the forums are concerned... yes, please do join the conversations, ask questions, answer them if you can... the more the merrier.
-
Not entirely true...
Looks like you might have used a different Delphi then... ;)
Under Delphi, which was actually a bunch of junk piled on top of TP7, you had no choice but to use some of the OOP stuff since the compiler linked in a number of classes for error handling and such... Even if you went outside the IDE and worked in notepad with the command line compiler, you ended up with OOP code...
Delphi (and certainly the 32bit versions since Delphi 3.0) was pretty much a complete new compiler from scratch with very little in common with any previous DOS based compiler.
The killer was when I wrote an MCI command in Delphi to play a midi file from the command line and the program ended up being over a megabyte... The same program was 16k in C.
I am pretty sure that you are comparing apples and oranges here. I have written in the past a small Windows based POS system with some midi files playing for audio feedback, and that whole program fit on a 1.44MB floppy disk, including about a dozen external .MDI files!
Except for the lack of a string type (and even Delphi had to translate it's strings for Win-API) the only real advantage to Pascal is it's garbage collector... the rest is pretty much "C with an accent" as one of my students put it.
Working with a pChar in Delphi is magnitudes simpler than anything you can do in C...
And not to forget that IMHO Pascal has a far clearer syntax, type checking, etc, which makes programming a lot easier than doing the same things in C, even with a lot of programming discipline. And I use both, C and Pascal, for +30 years now...
Agreed ... if he would take on some help things might be a lot better. I don't know how much help I could be, but I'd be willing to do my part...
That's the point of working in a team, every one just has to do a little bit and one can concentrate of the part they are adapt to the most...
In the short term yes, a lot less work... but in the long run I'm glad I did the work, since Pascal actually is a dead fish...
Sorry, not by along shot... :P
It's more like the old pike hiding in the weeds to bit all those shiny fat carps in the butt! <LOL>
Actually, it's starting to look like I'm going to have to get some kind of setup going with the VC++ compilers from the SDK... they're about the only 32/64 bit compilers that are compatible with the full set of windows headers and libs... (And no, that's not a choice I wanted to make!)
Well, then you can certainly kiss your 16KB command line midi tool good by... <BFEG>
Ralf
-
Not entirely true...
Looks like you might have used a different Delphi then... ;)
Actually no... But I did devise a patch for the RTL that would let me compile programs without classes...
The killer was when I wrote an MCI command in Delphi to play a midi file from the command line and the program ended up being over a megabyte... The same program was 16k in C.
I am pretty sure that you are comparing apples and oranges here. [/quote]
Two programs with exactly the same MCI string command in them and nothing else... Source code in the area of 10 lines... Delphi produced a 1 meg executable, Pelles C did it in just under 16k.
And not to forget that IMHO Pascal has a far clearer syntax, type checking, etc, which makes programming a lot easier than doing the same things in C, even with a lot of programming discipline.
Easier yes... but seldom more efficient.
The original Turbo Pascal would commonly produce executables the same size as C, sometimes even smaller... Delphi, well, that was like walking off a cliff.
Agreed ... if he would take on some help things might be a lot better. I don't know how much help I could be, but I'd be willing to do my part...
That's the point of working in a team, every one just has to do a little bit and one can concentrate of the part they are adapt to the most...
Yep.... but I've always been the lone wolf type... I definately work best on my own.
Actually, it's starting to look like I'm going to have to get some kind of setup going with the VC++ compilers from the SDK... they're about the only 32/64 bit compilers that are compatible with the full set of windows headers and libs... (And no, that's not a choice I wanted to make!)
Well, then you can certainly kiss your 16KB command line midi tool good by... <BFEG>
Sigh... so it would seem...
Remember when programming used to be fun?
-
I think to remember that Pelle is looking after his father due to he being ill.
We have currently written our own GUI framework for UltraDefrag, but it is really hard to do things in pure ANSI C.
Now we look at utilizing wxWidgets, but that is C++, so we face another problem :P
Libraries and frameworks for ANSI C would help keeping it lively.
-
Tater,
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.
James
-
I think to remember that Pelle is looking after his father due to he being ill.
Of course, we give Pelle all the slack he needs for that... The real concern is why he wouldn't take on a couple of helpers to keep things going while he's otherwise occupied.
We have currently written our own GUI framework for UltraDefrag, but it is really hard to do things in pure ANSI C.
Now we look at utilizing wxWidgets, but that is C++, so we face another problem :P
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.
Libraries and frameworks for ANSI C would help keeping it lively.
Absolutely.... Over the years I've put up everything from wrapper libraries for file associations to custom controls... What surprises me is that there aren't more of these floating around.
-
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...
-
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.
-
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 (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 :P - 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.
-
Hi Migf1 ... sorry for the delay, had to give your comments some thought first :D
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?"
-
Hi Migf1 ... sorry for the delay, had to give your comments some thought first :D
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 (http://x-karagiannis.gr/prg/c-prog/c-misc/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.
-
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.
-
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. (http://blogs.msdn.com/b/vcblog/archive/2012/09/12/10348456.aspx) 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.
-
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.
-
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 (http://www.zdnet.com/oracle-will-support-hp-itanium-systems-can-fud-damage-be-reversed-7000003770/) in terms of supporting it's database for HP's Itanium based servers...
Ralf
-
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.
-
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...
-
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 (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/ (http://x-karagiannis.gr/prg/custom/doc/con_color/html/), d/l: https://www.box.com/s/vskpxjwb0p3vlb1ymr5q (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/ (http://www.resedit.net/) b) http://melander.dk/reseditor#comments (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 (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.
-
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
-
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
-
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.
-
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, 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
-
Well, I think I mentioned the "Catch 22"/"Chicken and egg" problem in one of my previous posts... :'(
:D So you can take my comment as "By way of agreement..."
-
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?
-
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.
-
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...
-
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
-
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.
-
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
-
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 (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... ;D).
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.... 8)).
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.... ;)
-
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.
( :D By way of agreement, of course.)
-
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.
-
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! :-[ :-\ :-X
Ralf
-
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. 8)
This is why LINUX can be moved from one HW to another in a couple of days....
-
Ei verbibbscht! :-[ :-\ :-X
The world is still turning, so no problem ;)
-
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. 8)
This is why LINUX can be moved from one HW to another in a couple of days....
Android seems to have taken this approach much further, since it runs more or less as a VM.
The future is about mobile devices, but stationary ones will still be needed for high performance use.
If there would be an abstraction layer that offers a common interface to the software and is working on every operating system, things would be much easier.
A common architecture like below would be nice.
- Hardware
- HAL
- Operating system
- OSAL
- Software
-
Stefan,
indeed there is: POSIX ;D
On POSIX is based X-Window that leads to GTK, etc.
But commercial SW don't like to conformate too much :'(
Anyway your list make me remember of networking ISO-OSI standard (7 levels from phisycal to application), at the end it won (even if not all levels are always present) to allow different products to work together. Maybe in far far future this will happen if something new will come out to induce producers to talk same language.... :)
P.S. some technologies like MS COM (Component Object Model) are already available to different systems as DCOM (Distribuited Component Object Model).
DCOM is still MS patent, but available on LINUX, SOLARIS, etc.
-
Yes Tater, but writing in ASM has a couple of drawbacks:
Hi Frankie,
Thank you for such a nice explaination of hardware abstraction.
I've known some of this for a while and I agree that ASM has this particular drawback of not being portable but then very little compiled code is portable... mostly what people are "porting" is source code.
However; ASM also has the advantage of producing high performance code, as is needed for many kernel and driver level functions. So the tradeoff is that hardware manufacturers most often provide the core driver for a given device (chip, board, disk etc.) and these are in turn interfaced to the OS through an abstraction layer as you indicated.
It ain't perfect... but it obviously does work.
-
Hi Stephan...
Android seems to have taken this approach much further, since it runs more or less as a VM.
The future is about mobile devices, but stationary ones will still be needed for high performance use.
Java was supposed to be one of thosie "universal API" interfaces. The idea being that a hardware producer could provide an abstraction layer that was common to all systems, then programmers could write code that worked on all systems. The only real problem was that Java was basically a giant and cumbersome interpreter... with all the problems that implies.
.Net was another attempt at this and only now is MS realizing the degree of bloat it imposed on user's systems.
The future may be about mobile devices --I shudder to think of all the crap people will be carrying with them-- but, as you point out, most of the really good stuff will still be happening on workstations.
-
However; ASM also has the advantage of producing high performance code, as is needed for many kernel and driver level functions.
Hi Tater :)
That's not really true, some really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes, but anyway you have to consider that a driver code is the very core part of hardware access so it don't use any library or other bloated code. Normally the use of port I/O instructions is enough, so translation from C to assembler is straightforward.
Moreover as already said most of the code is always in C and only the real low level is in assembler.
About fast code just an example: if you look at the video codec free libraries you will find that many of the computational core software is also available in assembler, but the precompiled libraries always use the C coded one (because is faster to compile & debug and because the assembly sample is tailored for a processor: penthium, PII, PIII etc). Anyway anybody can play a full-HD movie with no difference to notice..... ::)
-
Hi Tater :)
That's not really true, some really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes, but anyway you have to consider that a driver code is the very core part of hardware access so it don't use any library or other bloated code. Normally the use of port I/O instructions is enough, so translation from C to assembler is straightforward.
Moreover as already said most of the code is always in C and only the real low level is in assembler.
This I knew. ASM is used only in very specialized cases these days. Still the advantages and disadvantages are about as we've said.
As an application programmer, I very seldom have any need to dip into ASM and only rarely need to mess with anything but Windows API, so I'm always glad of the reminders for what does what best :D
-
some really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes
That is probably true. It would be nice if Microsoft used these compilers for the C Runtime Library - here are some randomly picked comparisons between assembler and CRT functions.
Intel(R) Celeron(R) M CPU 420 @ 1.60GHz (MMX, SSE, SSE2, SSE3)
Comparing two strings which differ at position 500,000:
189 ms for StringsDiffer (asm), 1000 differences found
970 ms for strcmp (CRT), 1000 differences found
Comparing two strings, case-insensitive, ca. 955 kBytes:
653 ms for StringsDiffer, 0 differences found
2097 ms for CRT strcmpi, 0 differences found
Get the overall length of the first string:
194 ms for Asm Len, 977412 bytes found
616 ms for CRT strlen, 977412 bytes found
EDIT: Added a small change to prevent it from crashing if a binary file was submitted via the commandline.
-
some really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes
Interesting ... Was that Pelles CRT or Microsoft's?
There is this concept called "Premature Optimization" that can be quite the trap if you aren't careful. This is the case when you spend 6 months developing and debugging something that shaves 10ms off a program's execution time. Unless the program itself is essentially time critical what you've really done is spend an enormous amout of time on what amounts to a microscopic improvement.
Using the ASM versions can be a real advantage if you have large arrays of long strings, say, for example, a list of 100,000 1meg buffers from some hyper fast disk array. But what is the gain if you are comparing a user's name and password in a list of 50 people? It's over in a heartbeat either way, the user won't even notice the time difference and how much work did you do for that?
This is not to trash ASM, in fact, I'm guessing that the best performing CRTs are largely ASM... but it does raise the question about the time and effort put forth as opposed to the time and effort saved. If you're going to save your user 5ms while logging in, forget it, not worth doing... if you're going to do real time logging from a 1gbps hard disk array, well, maybe it's worth it.
-
So Tater, if I understand you correctly, you write that Frankie's remark about optimising compilers better than Asm is completely irrelevant because speed doesn't matter?
(on the other hand, why is it that MS Office & Firefox & Adobe's crap are so incredibly slow... :o)
-
So Tater, if I understand you correctly, you write that Frankie's remark about optimising compilers better than Asm is completely irrelevant because speed doesn't matter?
I did not and would not say that speed doesn't matter and no way do I think the optimizing compilers are pointless. You are saying that I said that. Please do not put words in my mouth so that you can argue with them ... that won't earn you any friends on this end.
What I said was that in many cases speed is less important than most programmers seem to think it is... Why do you need sub-millisecond functions in a program that spends 99% of it's time waiting for you to click a mouse? Then on the other hand you absolutely do need them in a program that's processing huge quanties of streaming data... It's a question of sensible priorities.
http://scientopia.org/blogs/goodmath/2011/05/03/the-perils-of-premature-optimization/ (http://scientopia.org/blogs/goodmath/2011/05/03/the-perils-of-premature-optimization/)
http://greybeardedgeek.net/2011/04/08/premature-optimization/ (http://greybeardedgeek.net/2011/04/08/premature-optimization/)
-
That Assembler (btw, where is the assembler here) vs. C example is most likely comparing apples and oranges here anyway.
Without seeing the corresponding C source code, I would strongly convinced that the C code is taking at least some precaution of dealing with Unicode strings, while the supposed to be assembler code seems to process single byte character strings only.
Ralf
-
I did not and would not say that speed doesn't matter
Thanks for the clarification, Tater 8)
"There is this concept called "Premature Optimization" that can be quite the trap if you aren't careful."
I love that one, Tater. And I promise I'll be careful from now on.
-
Without seeing the corresponding C source code, I would strongly convinced that the C code is taking at least some precaution of dealing with Unicode strings,
... error trapping, localization, character translation...
-
Without seeing the corresponding C source code, I would strongly convinced that the C code is taking at least some precaution of dealing with Unicode strings, while the supposed to be assembler code seems to process single byte character strings only.
Ralf,
Why don't you just look under the hood? Here is the innermost loop of MSVCRT strcmpi:
77C183B0 0AC0 or al, al
77C183B2 74 2E je short 77C183E2
77C183B4 8A06 mov al, [esi]
77C183B6 46 inc esi
77C183B7 8A27 mov ah, [edi]
77C183B9 47 inc edi
77C183BA 38C4 cmp ah, al
77C183BC 74 F2 je short 77C183B0
... and voilà, no check for Unicode.
But if you like true Unicode, let's add a test:
Intel(R) Celeron(R) M CPU 420 @ 1.60GHz (MMX, SSE, SSE2, SSE3)
Find a string in a UTF-16 file, Chinese text:
388 ms for Asm wInstr, match found at pos 12031 (10,000 loops)
636 ms for CRT wcsstr, match found at pos 12031 (10,000 loops)
Find a string in a UTF-16 file, Chinese text, case-insensitive:
389 ms for Asm wInstr, match found at pos 12031 (10,000 loops)
1343 ms for StrStrIW, match found at pos 12031 (one-thousand loops)
Find a string in a UTF-16 file, short Russian text, case-insensitive:
225 ms for Asm wInstr, match found at pos 562 (100,000 loops)
638 ms for StrStrIW, match found at pos 562 (ten-thousand loops)
There is apparently no CRT equivalent for the case-insensitive wInstr(), so the Microsoft-recommended option seems to be StrStrIW of ShlWapi. Note that in the timings above, StrStrIW does only 10% of the loops, otherwise you could go for a coffeebreak...
P.S.: Just in case: Yes,.wInstr does use LCMapStringW. Still strongly convinced?
;)
-
I think this thread has been evolved into the definition of "off-topic" :lol:
Anyway, I'll stick to my original stand, unless I'm convinced otherwise by others...
a) Open Source gives much more motivation for more people to actively involve in a project, plus it gives them the chance to embed any improvements (and/or bugs :P ) right into the original code, with any implied pros and cons compared to external patching
b) A platform that has officially dropped the use of a particular programming language for a long time, in favor of other langs and tools, has a huge negative impact in (not) motivating people to involve in a project that deals with that officially long dropped language. Especially when at least another popular platform is evolving in parallel using that programming language as its point of reference (e.g Gnome/GNU)
-
a) Open Source gives much more motivation for more people to actively involve in a project, plus it gives them the chance to embed any improvements (and/or bugs :P ) right into the original code, with any implied pros and cons compared to external patching
It may, but it doesn't need to be like that. You'd be surprised if you knew how many 3rd party ideas have been incorporated into Pelles C over the years... The Open Resouce as text addin now sits as a menu choice in the resource editor, the WIN32_DEFAULT_LIBS idea was originally mine and is now part of the standard headers, and on and on.
Even Open Source isn't really open source... most of these projects are governed by committees --often a commitee of one-- who decide what does and does not make the final cut. The only real difference between commercial software departements and an Open Source project is that the commercial guys get paid for their work.
b) A platform that has officially dropped the use of a particular programming language for a long time, in favor of other langs and tools, has a huge negative impact in (not) motivating people to involve in a project that deals with that officially long dropped language. Especially when at least another popular platform(s) is evolving in parallel using that programming language as its point of reference (e.g Gnome/GNU)
This is merely a matter of perception and I dare say not a very smart perception. How do you explain Free Pascal, D, Python, ADA and a dozen flavours of Basic? Should those highly active projects just give it up and go home because Microsoft isn't using any of those languages?
No offense my friend, but as a couple of us have pointed out your analysis is based on a flawed premise.
-
It may, but it doesn't need to be like that. You'd be surprised if you knew how many 3rd party ideas have been incorporated into Pelles C over the years... The Open Resouce as text addin now sits as a menu choice in the resource editor, the WIN32_DEFAULT_LIBS idea was originally mine and is now part of the standard headers, and on and on.
Even Open Source isn't really open source... most of these projects are governed by committees --often a commitee of one-- who decide what does and does not make the final cut. The only real difference between commercial software departements and an Open Source project is that the commercial guys get paid for their work.
The real question to be asked should be, imho: how will you convince more people to get involved? Obviously the examples your are mentioning, have not convinced more people to get involved for many years now (otherwise you wouldn't have posted your original question, I guess).
This is merely a matter of perception and I dare say not a very smart perception. How do you explain Free Pascal, D, Python, ADA and a dozen flavours of Basic? Should those highly active projects just give it up and go home because Microsoft isn't using any of those languages?
No offense my friend, but as a couple of us have pointed out your analysis is based on a flawed premise.
No offense tater, but I can very easily direct your "flawed premise" argument toward your analysis. Most, of the toolsets you are listing above to support your analysis are either cross-platform by nature or they provide cross-platform development tools and/or environments. Pelles-C simply does not.
-
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.
Nope, that's not true! gcc is a pure C compiler (g++ is a pure C++ compiler). Let me remind you (or inform you, if your are not already aware of it) that GCC was originally an acronym for "GNU C Compiler", exactly because it was exactly a C compiler only (I was using it as a student back then, in late '80s). Support for other languages came later on, and thus the GCC "interpretation" was changed to "GNU Compiler Collection".
So gcc does not "just happen" to compile plain C, it is a pure C compiler. g++ is a C++ compiler that happens to compile some plain C code (as most c++ compilers do).
There isn't another straight C compiler out there (ok, lcc, which Pelle's C in based on in the past) for Windows...
Ralf
That's not true either! You may wish to have a look at this Wikipedia link: http://en.wikipedia.org/wiki/List_of_compilers#C_compilers (http://en.wikipedia.org/wiki/List_of_compilers#C_compilers).
-
No offense tater, but I can very easily direct your "flawed premise" argument toward your analysis. Most, of the toolsets you are listing above to support your analysis are either cross-platform by nature or they provide cross-platform development tools and/or environments. Pelles-C simply does not.
Yes, you're correct... Pelles C is not a cross-platform tool.
However, you seem to be missing one crucial point ... We don't want it to be cross-platform. Get it? Cross-platform development is not one of Pelles C's goals... nor should it be. It is designed to be Windows Specific and IMO it needs to stay that way.
In fact, I don't give two warm sh_ts what happens on any other OS... if Pelle opens it up and goes "cross-platform" with it, I'll drop it like a hot potato.
-
Can we, maybe, get back to the original discussion...
Seriously, I don't think trying to sell cross-platform ideologies or ASM's superiority is helping the discussion one bit.
I would like to see some honest discussion of if and how we should work to support Pelles C...
If it's dead, lets let it die a graceful death of neglect (as it is now).
If it's not dead, lets get behind it and bring some life to the project.
-
No offense tater, but I can very easily direct your "flawed premise" argument toward your analysis. Most, of the toolsets you are listing above to support your analysis are either cross-platform by nature or they provide cross-platform development tools and/or environments. Pelles-C simply does not.
Yes, you're correct... Pelles C is not a cross-platform tool.
However, you seem to be missing one crucial point ... We don't want it to be cross-platform. Get it? Cross-platform development is not one of Pelles C's goals... nor should it be. It is designed to be Windows Specific and IMO it needs to stay that way.
In fact, I don't give two warm sh_ts what happens on any other OS... if Pelle opens it up and goes "cross-platform" with it, I'll drop it like a hot potato.
Of course I get it!
Well, in that case I sincerely wish you all the luck in motivating people to invest their free time in an outdated approach of developing Windows software. Even for bringing it up to or close to the VS Express standards (and/or free IDEs+mingw standards) explicitly for the Windows platform.
-
Nope, that's not true! gcc is a pure C compiler (g++ is a pure C++ compiler). Let me remind you (or inform you, if your are not already aware of it) that GCC was originally an acronym for "GNU C Compiler", exactly because it was exactly a C compiler only (I was using it as a student back then, in late '80s). Support for other languages came later on, and thus the GCC "interpretation" was changed to "GNU Compiler Collection".
So gcc does not "just happen" to compile plain C, it is a pure C compiler. g++ is a C++ compiler that happens to compile some plain C code (as most c++ compilers do).
Sorry, you are missing the point here...
Yes, GCC/gcc stands for quite a while for "GNU Compiler Collection", but my point is if you feed a mix of C and C++ code to it (g++ as the executioner, AFAIK at least since GCC4, there is no separate C compiler executable anymore), it will happily do so, unless you get wild with command line switches to force "C only". That doesn't not fit IMHO the definition of a pure C compiler...
Not to mention that none of the GCC compilers is in fact a true Windows compiler either, the all need to use a crutch of a *ix porting library to produce Windows programs...
There isn't another straight C compiler out there (ok, lcc, which Pelle's C in based on in the past) for Windows...
That's not true either! You may wish to have a look at this Wikipedia link: http://en.wikipedia.org/wiki/List_of_compilers#C_compilers (http://en.wikipedia.org/wiki/List_of_compilers#C_compilers).
So, which one to be precisely? At least considering the same price tag and functionality...
Ralf
-
In fact, I don't give two warm sh_ts what happens on any other OS... if Pelle opens it up and goes "cross-platform" with it, I'll drop it like a hot potato.
Well, on the other hand, you quite happily picked it up, despite the additional support for ARM/Windows CE... ;)
IMHO, opening up Pelle's C doesn't have to mean that there has to be a Pelle's C for Linux or Pelle's C for Mac, there are already plenty entrenched tools out there, no need to add to the mix. Instead there should be a concentrated effort to solidify the Windows environment.
But as I mentioned, dropping the certainly outdated Windows CE and instead use (and enhance) the existing ARM compiler to support cross-development (on Windows) for the Raspberry Pi could attract more users that otherwise wouldn't be really aware of it...
Ralf
-
Well, on the other hand, you quite happily picked it up, despite the additional support for ARM/Windows CE... ;)
At the time (ver 2.90) that wasn't seen as a separate OS, it was depicted as an extension of windows for mobile devices and shared many features of windows.
Instead there should be a concentrated effort to solidify the Windows environment.
Which is what I've been saying all along....
CE is depricated since 6.5 ... and I doubt it will be missed when/if Pelle finally removes it.
-
I would like to expose some of my personal opinions in the hope they will be taken into consideration.
PellesC is a compiling suite created by Orinius Pelle a very smart swedish guy, who by himself wrote a bunch of software producing a very nice development environment targeted to MS world.
Pelle aim over all these years has been to stay as tight as possible to MS standards. The point was: whatever C project made for MS win (desktop or CE) should strightforfward compile on his suite.
Pelle also want not move to C++.
He offered the whole software free for any use, and in the meantime got some money selling sources to those who want them.
To free users was asked just to help development by testing code and reporting bugs.
While I don't know what would be the conditions if you buy sources (I mean if any support is included), for free use, even if donation was made, it should have been clear that the product was offered 'AS IS owned software'.
Pelle always programmed his suite as he liked, apparently accepting some suggestions and refusing many others. I said apparently because what was accepted in the 99% of cases was something present on MS suit.
His first long absence from the forum was when, very excited by the new IA64-AMD64 architecture, finally come back with a 64bits version.
Then maybe the decreasing interest in C projects from MS, maybe personal problems (his father had heart problems last year), maybe work and whatever else made him busy elsewhere.
Anyway this product is Pelle's child and he has the right to do with it whatever he wants, although he never let users with an outdated version (one that doesn't include all features to compile with last MS-WIN version).
Maybe he is working on Win8 8)
Finally if you like PellesC suite you must take it as is..... ;D
-
The point was: whatever C project made for MS win (desktop or CE) should straightforward compile on his suite.
That is already a very reasonable goal. I don't code a lot in C, but whenever I find a code snippet on the web that I'd like to see in action, VS Express tells me it has to convert this incredibly old project, then it tries conversion, and fails miserably :(
Pelle's C succeeded in several cases where VS failed. Now the point is that there must be tons and tons of C sources that rely on some reasonable standard settings. Apparently M$ has no interest in C any more, let alone backward compatibility, so this might be an excellent market niche for Pelle. "What, your code is more than three years old? Forget Microsoft, try Pelle's C!" - add a bit of support, and you can earn a living...
-
I would like to expose some of my personal opinions in the hope they will be taken into consideration.
...
Finally if you like PellesC suite you must take it as is..... ;D
Excellent post Frankie and very well said.
What I'm hoping we can do is ADD to what Pelle offers to give a more complete suite of headers, libs and 3rd party libraries. None of this implies making changes to Pelles C or POASM... only adding our own stuff in support of what's already there.
What better test is there than to see it in popular use?
-
Pelle's C succeeded in several cases where VS failed. Now the point is that there must be tons and tons of C sources that rely on some reasonable standard settings.
Of course there are... and they're not all 5 or 10 years old... New stuff is being written every day.
Many universities have reinstated C courses... because they're finding that OOP languages in general are a lousy way to learn programming principles. Many corporate IT departments use C for "quicky" projects, such as re-dating a data base or making backups. Plus I'd bet real money that someplace in the bowels of Microsoft there is a team working in pure C on some of the stuff that gets awkward in C++ (etc).
Just because MS is moving to C++ does not mean that C is dead... it means only that MS is moving to C++.
-
Just a quick question: Does a C/C++ compiler compile an all C source program the same way that a C only compiler does? If I remember correctly, are there not a handful of C functions that behave differently under C++? So, (asking it another way), when a C++ compiler finds one of the functions, does it compile the code as it would under C++ or C?
-
Just a quick question: Does a C/C++ compiler compile an all C source program the same way that a C only compiler does? If I remember correctly, are there not a handful of C functions that behave differently under C++? So, (asking it another way), when a C++ compiler finds one of the functions, does it compile the code as it would under C++ or C?
That might highly depend on the compiler you might be using...
In my experience, all those C++ compilers will compile proper C code, most differences between C and C++ in that case are that C++ is a bit more strict than C (which is most remedied in later ANSI standards,C99/C11).
For example it doesn't allow for arbitrary pointer conversions, you have to explicitly cast pointers, which IMHO rather improves the (maintainability of the) C code.
A common problem that I however see is that when using a C++ compiler, specially for someone not experienced with either C or C++, will inadvertently use C++ specific code that will never work in a plain C compiler...
Ralf
-
Thanks Ralf for the answer.
-
It is often needed to work with COM objects in windows.
To support Pelles C it would be best, to show people how to use COM-objects with plain C.
-
Just a quick question: Does a C/C++ compiler compile an all C source program the same way that a C only compiler does? If I remember correctly, are there not a handful of C functions that behave differently under C++? So, (asking it another way), when a C++ compiler finds one of the functions, does it compile the code as it would under C++ or C?
Give these a read...
http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
http://david.tribble.com/text/cdiffs.htm
-
Nope, that's not true! gcc is a pure C compiler (g++ is a pure C++ compiler). Let me remind you (or inform you, if your are not already aware of it) that GCC was originally an acronym for "GNU C Compiler", exactly because it was exactly a C compiler only (I was using it as a student back then, in late '80s). Support for other languages came later on, and thus the GCC "interpretation" was changed to "GNU Compiler Collection".
So gcc does not "just happen" to compile plain C, it is a pure C compiler. g++ is a C++ compiler that happens to compile some plain C code (as most c++ compilers do).
Sorry, you are missing the point here...
Yes, GCC/gcc stands for quite a while for "GNU Compiler Collection", but my point is if you feed a mix of C and C++ code to it (g++ as the executioner, AFAIK at least since GCC4, there is no separate C compiler executable anymore), it will happily do so, unless you get wild with command line switches to force "C only". That doesn't not fit IMHO the definition of a pure C compiler...
Not to mention that none of the GCC compilers is in fact a true Windows compiler either, the all need to use a crutch of a *ix porting library to produce Windows programs...
MinGW32 and all its variants/distributions, e.g. MinGW64, TDM, etc are producing native Win executables, and that's all that should matter in the context of this discussion, or so I think.
Likewise, yes GCC has unified many languages under the same umbrella, but it does use separate "front ends" for each language (that's how it calls them). At the end of the day, we don't really care how a C compiler works internally, and how many languages it supports, as long as it provides one or more ways to built a C specific executable, that is suffering the minimum possible "unification" overhead. In any case, the heart of GCC beats in much more C rates than C++, but again I think that's irrelevant in this discussion.
There isn't another straight C compiler out there (ok, lcc, which Pelle's C in based on in the past) for Windows...
That's not true either! You may wish to have a look at this Wikipedia link: http://en.wikipedia.org/wiki/List_of_compilers#C_compilers (http://en.wikipedia.org/wiki/List_of_compilers#C_compilers).
So, which one to be precisely? At least considering the same price tag and functionality...
Ralf
lcc, tinyc, portable c are pure c compilers.
But why should they be straight C? That's beyond me! mingw, watcom c, digital mars c, vs express have been used for pure C production on Windows for a long time, despite being C/C++ compilers. I fail to see what the problem is. It's not like I have suggested that Pelles C should include C++ (have I? LOL).
-
I would like to expose some of my personal opinions in the hope they will be taken into consideration.
PellesC is a compiling suite created by Orinius Pelle a very smart swedish guy, who by himself wrote a bunch of software producing a very nice development environment targeted to MS world.
Pelle aim over all these years has been to stay as tight as possible to MS standards. The point was: whatever C project made for MS win (desktop or CE) should strightforfward compile on his suite.
Pelle also want not move to C++.
He offered the whole software free for any use, and in the meantime got some money selling sources to those who want them.
To free users was asked just to help development by testing code and reporting bugs.
While I don't know what would be the conditions if you buy sources (I mean if any support is included), for free use, even if donation was made, it should have been clear that the product was offered 'AS IS owned software'.
Pelle always programmed his suite as he liked, apparently accepting some suggestions and refusing many others. I said apparently because what was accepted in the 99% of cases was something present on MS suit.
His first long absence from the forum was when, very excited by the new IA64-AMD64 architecture, finally come back with a 64bits version.
Then maybe the decreasing interest in C projects from MS, maybe personal problems (his father had heart problems last year), maybe work and whatever else made him busy elsewhere.
Anyway this product is Pelle's child and he has the right to do with it whatever he wants, although he never let users with an outdated version (one that doesn't include all features to compile with last MS-WIN version).
Maybe he is working on Win8 8)
Finally if you like PellesC suite you must take it as is..... ;D
Nice post! However, it just states what we already know. The original question was about our thoughts regarding helping Pelles C to become more popular, and I think this post does not help towards that direction.
Pelles C is a great piece of software, especially considering it's an one man project. But according to CommonTater (the original question poster) is not as popular as it should be (which is pretty much an established fact). We have been asked to present our thoughts about what will help it become more popular.
-
In a more general context (that is, without commenting on specific quoted posts) let me add to my original POV that Pelles-C is a very closed project in almost all aspects.
It relies on its own ide, its own libs, its own run-time, its own debugger, its own everything. This is quite understandable for an one man project, because it helps Pelle in having everything under control, and maintaining the project on his own. The AddIns are the only way provided for 3rd party support.
That was fine, as long as C was still fairly used for Win32 development, and as long there was not too much of a competition. Nowadays, things have changed drastically, as I have already presented in this topic. What Pelles C offers is no longer handy, trendy and/or unique. Being a very self-centric project does not really help in becoming more popular in todays standards.
For a moment (or more) lets forget about open source, cross-platform, etc. How about supporting project importing from other popular IDEs of today (e.g vs, code::blocks, dev-c++, netbeans, eclipse, the more the better). Or how about supporting popular CVS (git, mecrurial, etc)? Or how about a central place on the net for uploading/downloading installing/uninstalling AddIns from within the IDE? How about implementing stuff like Dev-C++'s devpacks (http://en.wikipedia.org/wiki/Dev-C%2B%2B#Devpaks)
Most of these stuff are the norm nowadays in most (if not all) serious development environments. The IDE itself could also benefit from some improvements too (like enhancing the editing capabilities for example, or like being able to move/auto-show sidebars and panels).
All in all, I can think and I have presented lots (and heterogeneous) of reasons of why Pelles C is not popular. Some of those can be implemented externally, others require access to the source code. The main question is how and who will be convinced to invest its free time on such things, since they are already available in a plethora of Pelles C's alternatives.
-
Nice post! However, it just states what we already know. The original question was about our thoughts regarding helping Pelles C to become more popular, and I think this post does not help towards that direction.
Maybe I was not clear enough ::)
PellesC is Orinius Pelle Product and he cand do whatever he wants!
You can only use it or not.
What to do to make it more popular? Write something usefull with PellesC project included, people to fast compile will download the suite and, if they like it, and like to program in WINAPI with plane C, maybe they will use it also in future 8)
PellesC++ actually seems to not be an option, in the future? The future of the suite is in Pelle's mind. ::)
-
It relies on its own ide, its own libs, its own run-time, its own debugger, its own everything. This is quite understandable for an one man project, because it helps Pelle in having everything under control, and maintaining the project on his own. The AddIns are the only way provided for 3rd party support.
Have you minimally considered that he sells the source?
-
Maybe I was not clear enough ::)
PellesC is Orinius Pelle Product and he cand do whatever he wants!
You can only use it or not.
What to do to make it more popular? Write something usefull with PellesC project included, people to fast compile will download the suite and, if they like it, and like to program in WINAPI with plane C, maybe they will use it also in future 8)
PellesC++ actually seems to not be an option, in the future? The future of the suite is in Pelle's mind. ::)
Of course it is Pelle's call. It couldn't be any other way. Still, how does this elaborate on the original question about why Pelles C is not popular? Or how does this help in making Pelles C considered a serious modern development environment?
Have you minimally considered that he sells the source?
Yes, it doesn't have to go open-source (nor cross-platform). There are so many other things mentioned by all of us in this thread.
But let me ask you this, have you minimally considered that nowadays closed projects do not motivate enough people in contributing to them? Too many commercial companies use/modify open-tools anyway, when their license allows them to (like gcc for example). This in turn increases the popularity of those open-tools.
-
But let me ask you this, have you minimally considered that nowadays closed projects do not motivate enough people in contributing to them? Too many commercial companies use/modify open-tools anyway, when their license allows them to (like gcc for example). This in turn increases the popularity of those open-tools.
Yes I have considered.
But I'm not interested in compiler developmet so *I don't care about the compiler sources*..
My sources can be used with *any* C compiler. PellesC IDE is nice I will use it, tomorrow I would use codebloks or eclipse or whatever....
Maybe is not clear what is the difference between: compiler - environment - IDE ::)
Anyway I'm no more interested in this topic...
-
Just a quick question: Does a C/C++ compiler compile an all C source program the same way that a C only compiler does? If I remember correctly, are there not a handful of C functions that behave differently under C++? So, (asking it another way), when a C++ compiler finds one of the functions, does it compile the code as it would under C++ or C?
For instance, my own main project is in plain vanilla ANSI-C for portability reasons (to embedded systems), there is no C++ code. For prototyping I am much more productive with Pelles C than with MinGW or Visual Studio. Reason: Pelles C is lightweight, fast, and offers all the tools that I need.
What else do I need to say that Pelles C is very alive here? Just because I contribute only occasionally to this forum, it is no "dead fish".
-
Hi Frankie...
Maybe I was not clear enough ::)
PellesC is Orinius Pelle Product and he cand do whatever he wants!
You can only use it or not.
Nobody is suggesting that Pelle change the project or even change his goals. I think most of us are quite happy with the "Feature Requests" and "Bug Reports" forums as improvement based channels.
What I am suggesting is that we do what Vortex recently did ... HERE (http://forum.pellesc.de/index.php?topic=5092.msg19466#msg19466) ... and make useful stuff available as separate downloads... The core project remains 100% under Pelles control (which suits me fine, btw) but now there's more a programmer can do with it.
That is... I believe the big reason it's fallen to disfavour --viewed mostly as a "beginner's tool"-- is that we users haven't gotten in there and fleshed it out... If we consider Pelles C, core project, as a "starting point" instead of as "the be all and end all" things look quite different...
What to do to make it more popular? Write something usefull with PellesC project included, people to fast compile will download the suite and, if they like it, and like to program in WINAPI with plane C, maybe they will use it also in future 8)
Yes, writing examples is a good idea.
-
What else do I need to say that Pelles C is very alive here? Just because I contribute only occasionally to this forum, it is no "dead fish".
Here too, akko. I used Pelles C daily as my main programming environment from 2004 to last fall when I sold off my commercial source code and retired. I've used to to write everything from tiny little console utilities all the way to a full blown parts inventory system with custom data bases. Pelles C is VERY alive around me.
However; our interests do not make a trend... I'd bet if you surveyed the people here, very few of those contributing to even this thread *actually use Pelles C* as a serious development tool. Like most, they see it as less than capable and are working in other IDEs or other Languages. This is what I'm hoping to understand...
I know the compiler is fully capable as is the linker and assembler... but the headers and libs are incomplete, some IDE improvements would be helpful (hense some of my AddIns)... yet nobody seems to want to chip in and help flesh it out. Only a couple of us are actively contributing AddIns, only half a dozen are making Contributions... and the downloads of these things are generally in single digits.
You and I using it as, I'm sure, Pelle would want to see it used --while a good thing-- probably aren't all that persuasive in the future of the project.
-
Ok... 6 pages of discussion and no closer to a concensus...
What I see is that Pelle's pet project is largely taken as is and used by very few who can work exclusively within it's limitations...
MigF1 is correct that it relies upon it's own IDE, Compiler, Debugger etc. This I think is a good thing. It's a tightly knit package that works very well together.
Frankie is right in that Pelle is the sole arbiter of the project's future.
But I see nothing that says we can't *add* to the project with our own downloadable modules of headers & libs to flesh out the Windows API support, or 3rd party libs to improve support in other areas... In fact, I'm dissapointed to see there's no ambition to do this at all... I've contributed several of my own libraries, custom controls, AddIns etc. to the project because it seems the right thing to do ... Pelle has given us this wonderful gift, so I try to return the favour with whatever little gifts I can...
Pelles C may not be a dead fish, but I get the feeling it's not very far from it...
-
It is not unlike many other good programming environments that have become "vintage" with time.
Pelle has invested a huge amount of his productive lifetime into his toolchain. If you have spent your life behind a microscope, you are bound to wake up one fine day finding your hair has gone gray and one of a few reamining summers is in front of your door...
Then it's about high time do some housekeeping and go for a nice long walk.
-
Then it's about high time do some housekeeping and go for a nice long walk.
Ain't that the truth.
-
For Pelle....
I thank you Sir, for Pelles C... I use it every day and I am extremely grateful for your generosity in sharing it.
-
If you have spent your life behind a microscope, you are bound to wake up one fine day finding your hair has gone gray and one of a few reamining summers is in front of your door...
Hi akko,
If you like science and if you are a biologist loving your profession, believe me there is no any reason for the dark panorama you described. Think about great people like Richard Feynman who enjoyed the mystery and beauty of science.
-
or is it worth supporting?
Some folks prefer C to C++, and AFAIK Pelles C is the only full featured C IDE that conforms to C standard (C99, C11).
Cross platform support is a nice thing to have, but some people don't need it.
MS nowadays is focusing their work in C++, not C.
I guess the answer is a symphatetic YES. :)
-
Hi Vortex
I know what you mean perfectly well, but where I live taking a break and a good walk is not considered as dark panorama. ;-) We usually return home full of new energy.
I sincerely hope that Pelle will continue maintaining his great compiler.
-
Hi,
here seems at last to be a place where some life exists .. so let me jump into the discussion.
I for myself stumbled upon PellesC some years ago when i was in the need to find a lightwight c compiler with a aceptable IDE that was finally able to do __declspec(naked) in the ASM part.
And guess what? you wont find any beside this bloated microsoft vehicle. Another important thing for me was that i would be able to package my entire project together with a working compiler IDE for distribution on a later state. So the question is what is he doing? I use PellesC for game modding and wrote my entire modmanager with it. I have to interface heavy codeparts written with PellesC with gamecode in binary format that i have no sources for with code injection and asm callstubs.. thats a nice challenge.
I personally think that a great brick in the way of more people using PellesC for real Developments is the incompytibility when using .dll files and headers prepared for other VC. For example i only managed to use some only when recreating my own .def and .lib files from the .dll.
At the moment im interested into integration of a webbrowser into my modmanager to entirely build my UI with it and struggling to get chromium or webkit to do something.. When i have success with it i will be glad to release a "Hello World" example project ready for PellesC. Additionally i managed long time ago to get SDL some giflibs, GD, allegro, SFML and some other libs working with PellesC.. for all i had to struggle to get the .dll versions to run without crash. Maybe we should start a board for collected efforts to get external librarys running with PellesC ?
Greetings
Seltsamuel
-
Ok... for what it's worth ...
I now understand why nobody is sharing source code or libraries.
It would be nice if the world didn't work the way it does...
But as we've seen in other threads, the price of generosity is just too high.