What makes C and C++ a "good" language?
-
The C and C++ languages are disastrous. They leave so many doors open for bugs and programming mistakes and they have other design failures (like header files that terribly slow down the compile time). The only valid reason for their existence is that most of today's libraries and operating systems are written using these languages. The interface of the majority of libraries and operating system APIs are still C based. Even if you try to replace these languages I think you need 3 different languages to build a whole operating system up on top of bare hardware. A minimal amount of assembly to communicate with hardware, a thin layer of relatively high level but unsafe language that allows for manual memory management in the low-level part of the operating system, and a high level safe language that can be used to write the top level of the operating system and the user programs. C/C++ could be something like the middle from these 3 languages but it would be easier to design a much better language than C/C++ with the same capabilities. Again, the only reason for the existence of C/C++ is massive amount of legacy code. EDIT: This post of mine became quite 'popular', for this reason I would like to link one of my other posts that contains a more comprehensive (but not full) list of my reasonings at the end of this quite long debate: http://www.codeproject.com/Messages/4377527/Re-What-makes-C-and-Cplusplus-a-good-language.aspx[^] Also would like to mention that I have extensive background in low level programming including assembly, C, and C++, reverse engineering and I'm not a 'just because'-type of hater of C/C++ who used only scripts and managed languages - I don't hate C/C++ at all. I respect these languages because they have been fun for me to program in, they helped the world to become better, but we have to see their obvious defects as well. Thanks for reading.
Regarding the power and the popularity: Being the language that was used to develop both windows and Linux operating systems is a proof that supports c\c++ as the best middle level languages not the contrary. I think this is because accidentally c++ was the first most complete in logic language that has been invented, since then, even now.So most of people learned it and wrote their programs with it. That is why it became the most popular. The fact that most of people use it and recommend it for their friends because they don't know except it, i think this is false, especially for the professional programmers who do this for living. You will find most of them master more than 3 or 4 languages. Most of the people still use it because it is still valid for most of purposes. You can code for any operating system, any new device. For example if I'm using vb can i code programs for i pad??!! So i agree with you for coding for general purposes you or we can chose any other easier language, this is correct, and i support, but regarding serious issues and for those who want to program for many purposes being real professionals you will find yourself forced to chose c++. Regarding load and other technical issues: Sorry, the reasons you mentioned for considering C++ not the optimal language, for example the arrange of header files, i think it returns to your team bad choices not to the language itself. The lines of code are compiled the order you put. Even if we agree and i agree that there is nothing optimal, especially at the field of science, and we are expecting the better. Tell me what is the alternative you propose to get rid of C++. I accept all alternatives. Is there anybody find something makes his life easier and not following it. I think he is ........ hahaha. You my dear mentioned the problem without mentioning the solution. Propose a solution and let us discus. The fact is , i think , it is difficult and expensive to write a new language like that one you and we dream of. Even if some company did so, and i think some did especially Microsoft, they wouldn't release it for commercial use easily like that. That would be one of the company precious treasures, and will be kept as a secret. No one these days invent something makes his work easily and let it go in public like that. Regarding the market side: Microsoft is trying to kill C++ to control the market when they make all visual studio equal regarding linking and compiling but i thing they wouldn't succeed, because they live on t
-
CPallini wrote:
I can't believe that (comparing with C language).
Anyway your quickly compiled project would suck in performance, compared to a similar C/C++ one.The time you win in another language comes from the fact that there is no header hell, and the parsing of the language is much simpler. For example delphi uses unit files that contains ready-made data for the compiler (the same is true for a lot of other languages), in C/C++ you have to read in and parse and compile the same header files a dozen times. This becomes even worse if the headers contain a lot of inlining and/or templates. The parsing and compiling of C++ is also much more complex for the compiler frontend than the same for some other languages like pascal/delphi. This has nothing to do with optimization. Anyway, any other language can use the exact same optimizations as C++ (see llvm).
CPallini wrote:
This is a nonsense. The 'underlying compiler architecture' depends on the language. Almost all other programming languages are outperformed by
C++. That's a fact.@See llvm.
CPallini wrote:
We were not talking about that. We were talking instead about backward compatibility with C.
I was talking about C++'s compatibility with C++. But the same is almost true for C's compatibility with C but this isn't so big problem because C is much simpler. With some modifications (like eliminating header files and some more type safety) C could be a nice simple language.
Again you didn't understand. C language compilation is relatively fast. C++ language compilation, on the other hand is slow, I am aware of it. Anyway you cannot achieve the same performance of a (well) written C++ application with a (well) written application using your favourite programming language (try it). LLVM? Do you mean: "An aggressive open-source compiler for C and C++ and Stacker, a forth-like language"? :)
Veni, vidi, vici.
-
Regarding the power and the popularity: Being the language that was used to develop both windows and Linux operating systems is a proof that supports c\c++ as the best middle level languages not the contrary. I think this is because accidentally c++ was the first most complete in logic language that has been invented, since then, even now.So most of people learned it and wrote their programs with it. That is why it became the most popular. The fact that most of people use it and recommend it for their friends because they don't know except it, i think this is false, especially for the professional programmers who do this for living. You will find most of them master more than 3 or 4 languages. Most of the people still use it because it is still valid for most of purposes. You can code for any operating system, any new device. For example if I'm using vb can i code programs for i pad??!! So i agree with you for coding for general purposes you or we can chose any other easier language, this is correct, and i support, but regarding serious issues and for those who want to program for many purposes being real professionals you will find yourself forced to chose c++. Regarding load and other technical issues: Sorry, the reasons you mentioned for considering C++ not the optimal language, for example the arrange of header files, i think it returns to your team bad choices not to the language itself. The lines of code are compiled the order you put. Even if we agree and i agree that there is nothing optimal, especially at the field of science, and we are expecting the better. Tell me what is the alternative you propose to get rid of C++. I accept all alternatives. Is there anybody find something makes his life easier and not following it. I think he is ........ hahaha. You my dear mentioned the problem without mentioning the solution. Propose a solution and let us discus. The fact is , i think , it is difficult and expensive to write a new language like that one you and we dream of. Even if some company did so, and i think some did especially Microsoft, they wouldn't release it for commercial use easily like that. That would be one of the company precious treasures, and will be kept as a secret. No one these days invent something makes his work easily and let it go in public like that. Regarding the market side: Microsoft is trying to kill C++ to control the market when they make all visual studio equal regarding linking and compiling but i thing they wouldn't succeed, because they live on t
ah_ga_ah wrote:
for many purposes being real professionals you will find yourself forced to chose c++
Agree with the whole paragraph. Oh my god! Finally someone gets it!!! :-) Thank you!!!
ah_ga_ah wrote:
Sorry, the reasons you mentioned for considering C++ not the optimal language, for example the arrange of header files, i think it returns to your team bad choices not to the language itself.
This is at least a decade old legacy code, how the hell could we grow out 2 million lines of code? :-D :-D :-D Anyway an include hell can be rearranged in 1-2 days even in such a big project if you did it a few times. Just mentioned this to show that headers are bad in general because they give you one more unnecessary problem to look at. Such big codebase is usually grown by big companies who replace their people relatively often and not all of them are good or able to maintain some aspects of such a codebase. I'm also making mistakes. As a result more and more mistakes are made if the language allows that because noone is superman. Its sad but this is not the first big codebase I'm working with and most of them suffers from some problems that could be avoided with a good language that doesn't have the deficiencies of C/C++. C/C++ is way too allowing language.
ah_ga_ah wrote:
You my dear mentioned the problem without mentioning the solution. Propose a solution and let us discus.
Agree, I haven't mentioned a solution because "everyone knows" that there is no true alternative currently. I didn't want to do that, my post had a totally different purpose. I wanted to point out that having no alternative still doesn't mean that C/C++ stands it ground well in every aspect but you understood this.
ah_ga_ah wrote:
The fact is , i think , it is difficult and expensive to write a new language like that one you and we dream of.
Here comes the reason for my post: I think not every people are dreaming of that language. Lot of people know only C and/or C++ thinking that its the best language of the world for everything and they are just lying in the matrix without seeing the C/C++ defects. My post just wanted to open some eyes, but most of them is OK with their lives in the matrix. I guess you are the only poster in this discussion having some understanding of my cries. :-) The sum
-
Again you didn't understand. C language compilation is relatively fast. C++ language compilation, on the other hand is slow, I am aware of it. Anyway you cannot achieve the same performance of a (well) written C++ application with a (well) written application using your favourite programming language (try it). LLVM? Do you mean: "An aggressive open-source compiler for C and C++ and Stacker, a forth-like language"? :)
Veni, vidi, vici.
llvm was started to kill off gcc, so its first frontends are C and C++. Its a nice clean compiler infrastructure that already has other frontends and you can integrate any other languages relatively easy compared to the same work with for example gcc. Its a beam of hope to get rid of the "C++ is good because its the optimal" reasoning because that is simply ridiculous and still doesn't change the fact that both C and C++ are defective. And yes, compiling C is much faster, but on the other hand a C project is also much harder to maintain and the language features don't give much support to arrange huge codebases. The biggest C codebase was around 100.000 loc and it was already hard to navigate. The lack of type safety and typeless linking, lack of namespaces (and the list goes on) give way too much space for human errors. Yes, C code compiles faster but it misses lots of nice features that wouldn't require you to sacrifice compile speed.
-
llvm was started to kill off gcc, so its first frontends are C and C++. Its a nice clean compiler infrastructure that already has other frontends and you can integrate any other languages relatively easy compared to the same work with for example gcc. Its a beam of hope to get rid of the "C++ is good because its the optimal" reasoning because that is simply ridiculous and still doesn't change the fact that both C and C++ are defective. And yes, compiling C is much faster, but on the other hand a C project is also much harder to maintain and the language features don't give much support to arrange huge codebases. The biggest C codebase was around 100.000 loc and it was already hard to navigate. The lack of type safety and typeless linking, lack of namespaces (and the list goes on) give way too much space for human errors. Yes, C code compiles faster but it misses lots of nice features that wouldn't require you to sacrifice compile speed.
-
pasztorpisti wrote:
"C++ is good because its the optimal" reasoning because that is simply ridiculous
Your point is ridiculous. You have nothing to bear out it.
Veni, vidi, vici.
CPallini wrote:
Your point is ridiculous. You have nothing to bear out it.
Which point from the many listed in my posts?
-
CPallini wrote:
Your point is ridiculous. You have nothing to bear out it.
Which point from the many listed in my posts?
-
I will tell it to my mom! :-)
-
I will tell it to my mom! :-)
-
The C and C++ languages are disastrous. They leave so many doors open for bugs and programming mistakes and they have other design failures (like header files that terribly slow down the compile time). The only valid reason for their existence is that most of today's libraries and operating systems are written using these languages. The interface of the majority of libraries and operating system APIs are still C based. Even if you try to replace these languages I think you need 3 different languages to build a whole operating system up on top of bare hardware. A minimal amount of assembly to communicate with hardware, a thin layer of relatively high level but unsafe language that allows for manual memory management in the low-level part of the operating system, and a high level safe language that can be used to write the top level of the operating system and the user programs. C/C++ could be something like the middle from these 3 languages but it would be easier to design a much better language than C/C++ with the same capabilities. Again, the only reason for the existence of C/C++ is massive amount of legacy code. EDIT: This post of mine became quite 'popular', for this reason I would like to link one of my other posts that contains a more comprehensive (but not full) list of my reasonings at the end of this quite long debate: http://www.codeproject.com/Messages/4377527/Re-What-makes-C-and-Cplusplus-a-good-language.aspx[^] Also would like to mention that I have extensive background in low level programming including assembly, C, and C++, reverse engineering and I'm not a 'just because'-type of hater of C/C++ who used only scripts and managed languages - I don't hate C/C++ at all. I respect these languages because they have been fun for me to program in, they helped the world to become better, but we have to see their obvious defects as well. Thanks for reading.
pasztorpisti wrote:
have other design failures (like header files that terribly slow down the compile time)
That's not a design failure. Something other woudln't be possible at that time. First Header-Files were made for easy reading classes. There was no Syntax-Highlighting or code-analysis while editing. You had jsut the VI. Second Point: It was easier to compile that with 16kb or less many machines had in those days, instead of building crossreferences at compiletime.
pasztorpisti wrote:
A minimal amount of assembly to communicate with hardware, a thin layer of relatively high level but unsafe language that allows for manual memory management in the low-level part of the operating system, and a high level safe language that can be used to write the top level of the operating system and the user programs
I think Oberon can do all three levels. But who programms in Oberon at all?! :-\ C/C++ is fast, lean but it's not designed for everything. It's good to be backend for complex algorithms but not for frontend. There are tools which close all memory leaks, but they are very expensive.
------------------------------ Author of Primary ROleplaying SysTem How do I take my coffee? Black as midnight on a moonless night. War doesn't determine who's right. War determines who's left.
-
The less mistakes a language lets to make, the better the language is. Its not real knowledge to learn to deal with the idiotic features of a complex language. If you work in a big team its more likely that someone will be unable to "design". On the other hand the header include are nowhere for example compared to turbo pascal/delphi units. Every other normal language uses some kind of "units" that contain data preprocessed for the compile to make things faster and easier. On the other hand only people how don't have experience with massive codebases don't feel the significance of the slow compilation times caused by header includes.
pasztorpisti wrote:
The less mistakes a language lets to make, the better the language is.
Wrong. If you spend even 10% of your time fixing "language" mistakes versus logic/design/requirements mistakes in your code then at best you are an atypical developer.
pasztorpisti wrote:
If you work in a big team its more likely that someone will be unable to "design".
If you work on a big team then it is almost 100% guaranteed that complexity issues will become the most serious development impediment.
pasztorpisti wrote:
Every other normal language uses some kind of "units" that contain data preprocessed for the compile to make things faster and easier....
As I already said, if you think this is a a significant problem in C/C++ then it is because there is a problem in the design. And the SAME exact problem can show up in Java/C# projects.
-
The sources of win2k have been leaked. Download them and look at the code. It contains tons of legacy code even from win31. Not to mention the backward compatibility between windows versions. Windows has never been rewritten.
pasztorpisti wrote:
It contains tons of legacy code even from win31.
Which would be relevant if I had claimed that they had written a newer version of windows from scratch using a black box development effort. But I am pretty sure that the vast majority of code is some command like 'type' has essentially remained the same since pre-win95. On the other hand I know for a fact what is required to move a code base that was originally written for 32 bits when that was new to what it takes to use a 64 bit system. How exactly do you think that windows handles VMing? Did you ever attempt the same thing in Windows 95? I can tell you that I did in fact run two OSes on a Win95 box and it was not easy.
-
I think I already answered this in a previous post. C/C++ simply can't be purged because of the huge legacy codebases. Better alternatives exist, the nearest to C++ is the D language. Its simple isn't used because it doesn't have library support that could compare to the legacy codebases for C++.
pasztorpisti wrote:
think I already answered this in a previous post. C/C++ simply can't be purged because of the huge legacy codebases.
And as I already said history is SPECIFICALLY full of cases where exactly that has happened. So obviously it can happen.
pasztorpisti wrote:
Its simple isn't used because it doesn't have library support that could compare to the legacy codebases for C++.
Wrong. It isn't used because developers have not found an advantage to using it. You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
-
Today there are shit loads of OSes, why would you want to write a new one? Anyway, 99% of the ongoing projects is not an operating system so you can pick from lots of other popular languages. In one of my previous posts I mentioned that there is no other similar low level language however by fixing some issues with C could result in a good one to write driver level stuff.
-
CPallini wrote:
Have you any proof supporting this sentence, regarding the C language?
Yes, in the last years we had many times when we had to rearrange the header includes and optimize for compile times for our CI system. We compiled the codebase (~2millions loc) with a grid system (IncrediBuild) plus SSD drives in all machines in the grid and the compile time was still 20 minutes. By rearranging some header files we could decrease the build time to around 5 minutes. Thats what I'm talking about not some few file hobby projects that make no sense to measure such things.
CPallini wrote:
This is an opinion (mine, for instance, is completely different).
And could you make a list of language features and compare that to some other languages that have better support for that? I see significant deficiencies in C++ comparred to some other languages, and its syntax because more-and-more complex with every new draft. A language that has redundant features and backward compatiblity with a thousand years old other language simply can't be "optimal".
pasztorpisti wrote:
Yes, in the last years we had many times when we had to rearrange the header includes and optimize for compile times for our CI system. We compiled the codebase (~2millions loc) with a grid system (IncrediBuild) plus SSD drives in all machines in the grid and the compile time was still 20 minutes. By rearranging some header files we could decrease the build time to around 5 minutes. Thats what I'm talking about ...
And what I am talking about is that is a poor design. Let us just suppose that there is absolutely no way that you can divide that into independent deliverables (each with a defined public interface.) It certainly wouldn't stop a well design code base in which one could still work effectively on a piece without using the entire code base. If it was designed correctly.
pasztorpisti wrote:
And could you make a list of language features
I use and have used all of the popular languages to make large systems. The features of the language have nothing to do with the success of the projects.
-
ah_ga_ah wrote:
for many purposes being real professionals you will find yourself forced to chose c++
Agree with the whole paragraph. Oh my god! Finally someone gets it!!! :-) Thank you!!!
ah_ga_ah wrote:
Sorry, the reasons you mentioned for considering C++ not the optimal language, for example the arrange of header files, i think it returns to your team bad choices not to the language itself.
This is at least a decade old legacy code, how the hell could we grow out 2 million lines of code? :-D :-D :-D Anyway an include hell can be rearranged in 1-2 days even in such a big project if you did it a few times. Just mentioned this to show that headers are bad in general because they give you one more unnecessary problem to look at. Such big codebase is usually grown by big companies who replace their people relatively often and not all of them are good or able to maintain some aspects of such a codebase. I'm also making mistakes. As a result more and more mistakes are made if the language allows that because noone is superman. Its sad but this is not the first big codebase I'm working with and most of them suffers from some problems that could be avoided with a good language that doesn't have the deficiencies of C/C++. C/C++ is way too allowing language.
ah_ga_ah wrote:
You my dear mentioned the problem without mentioning the solution. Propose a solution and let us discus.
Agree, I haven't mentioned a solution because "everyone knows" that there is no true alternative currently. I didn't want to do that, my post had a totally different purpose. I wanted to point out that having no alternative still doesn't mean that C/C++ stands it ground well in every aspect but you understood this.
ah_ga_ah wrote:
The fact is , i think , it is difficult and expensive to write a new language like that one you and we dream of.
Here comes the reason for my post: I think not every people are dreaming of that language. Lot of people know only C and/or C++ thinking that its the best language of the world for everything and they are just lying in the matrix without seeing the C/C++ defects. My post just wanted to open some eyes, but most of them is OK with their lives in the matrix. I guess you are the only poster in this discussion having some understanding of my cries. :-) The sum
pasztorpisti wrote:
Such big codebase is usually grown by big companies who replace their people relatively often and not all of them are good or able to maintain some aspects of such a codebase.
And of course none of that has anything to do with a specific language.
pasztorpisti wrote:
Its sad but this is not the first big codebase I'm working with
Perhaps you will get to work with a well designed system some day.
pasztorpisti wrote:
Lot of people know only C and/or C++ thinking that its the best language of the world for everything
Many people think that the language that the primarily use is the "best" language for any of a variety of things. Some even refuse to consider the possibility that any other language might be better for anything else. That however has nothing to do with a specific language.
pasztorpisti wrote:
but as a general purpose programming language it has way too many defects accumulated over the decades.
Of which you cite your personal observation of nothing more than slow compile times. And apparently at least one of which the 'best' choice was made to fix it by throwing hardware at it. I can assure you that any number of people have attempted to throw hardware at systems to fix performance problems which only produce marginal improvements. Looking at requirements, architecture and design however can lead to orders of magnitudes improvement. And that has nothing to do with language.
-
pasztorpisti wrote:
Yes, in the last years we had many times when we had to rearrange the header includes and optimize for compile times for our CI system. We compiled the codebase (~2millions loc) with a grid system (IncrediBuild) plus SSD drives in all machines in the grid and the compile time was still 20 minutes. By rearranging some header files we could decrease the build time to around 5 minutes. Thats what I'm talking about ...
And what I am talking about is that is a poor design. Let us just suppose that there is absolutely no way that you can divide that into independent deliverables (each with a defined public interface.) It certainly wouldn't stop a well design code base in which one could still work effectively on a piece without using the entire code base. If it was designed correctly.
pasztorpisti wrote:
And could you make a list of language features
I use and have used all of the popular languages to make large systems. The features of the language have nothing to do with the success of the projects.
jschell wrote:
And what I am talking about is that is a poor design.
Thanks for your advices, it had always been cut into about 10 DLLs. Still the CI system sometimes performed full clean build intentionally and that iteration time was important for us before relase days. Relatively rarely when some central system headers needed modification a grid came very-very handy. Of course I was talking about the full clean build time. I have to admit that the legacy codebase we are speaking about was full of lava code/flow and refactorization and/or partial rewrites in such a huge codebase is not always an option, its cheap neither in time nor in money. Still the owner wants to see it running and extending with new features. :P
jschell wrote:
I use and have used all of the popular languages to make large systems. The features of the language have nothing to do with the success of the projects.
A well chosen language and its development environment can cut the development/debugging (and maintenance!!!) time and the money spent considerably, so it has to do with the success of a project. Of course this isn't true if your company has infinite amount of time and money (I've already worked for one that seemingly had these traits... :-D).
-
pasztorpisti wrote:
Today there are sh*t loads of OSes,...
None of which answered the question.
I answered the question, you just forget to quote the end of my post. My posts are not advertising that we have true alternatives in every areas where C/C++ is used. I just mentioned that even in the areas where C/C++ has monopoly better alternatives could be forged with todays knowledge.
-
pasztorpisti wrote:
think I already answered this in a previous post. C/C++ simply can't be purged because of the huge legacy codebases.
And as I already said history is SPECIFICALLY full of cases where exactly that has happened. So obviously it can happen.
pasztorpisti wrote:
Its simple isn't used because it doesn't have library support that could compare to the legacy codebases for C++.
Wrong. It isn't used because developers have not found an advantage to using it. You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
jschell wrote:
And as I already said history is SPECIFICALLY full of cases where exactly that has happened.
So obviously it can happen.There is something in your statement. I guess languages are gone when they roots die. C/C++ have currently strong roots (at least Windows/*nix systems).
jschell wrote:
Wrong. It isn't used because developers have not found an advantage to using it.
I still think this is partly because of library support and development environment support. Its also a high risk to start a commercial project with something new that can blow. Lets imagine a fatal D compiler crash (without the support of the authors) in the middle of your project! Startups are very slow for these simple reasons.
jschell wrote:
You do understand that there are many C++ developers and yet C (not C++) continues to be used significantly? Do you understand how C++ was adopted over time to take over much of the work previously done by C++ and yet C by itself continues to be used? The first part of that puts lie to your contention that legacy code preclude new adoptions and the second to your assertion that something that is better in some way must always universally replace the older because there no longer is any value.
I guess you wanted to write C# when you were talking about the language that took over some of the work of C++. C# can became widespread (relatively quickly) because its supported by a huge rich company. Its library support is good, its IDE is superb. These give the base of one of your reasonings in a previous post: This language gave something. It made development easier and less risky because of the MS support. Noone makes you so nice IDE for D like the one you have for C#, same is true about support. Its not only the "coolness" and efficiency of the language that makes it widespread, money and/or time is also needed. As I mentioned previously I like the simplicity of C, by modifying it a bit (without keeping the ugly backward compatibility) I think it could be a very nice language for low level coding where C++ and its friends were too high.
-
pasztorpisti wrote:
It contains tons of legacy code even from win31.
Which would be relevant if I had claimed that they had written a newer version of windows from scratch using a black box development effort. But I am pretty sure that the vast majority of code is some command like 'type' has essentially remained the same since pre-win95. On the other hand I know for a fact what is required to move a code base that was originally written for 32 bits when that was new to what it takes to use a 64 bit system. How exactly do you think that windows handles VMing? Did you ever attempt the same thing in Windows 95? I can tell you that I did in fact run two OSes on a Win95 box and it was not easy.
Win95 is "just a nice DOS program". :-) Even if they have replaced and extended parts in the OS they always stayed backward compatible on api and source level and thats alone is a good reason for not switching the language even if all they do is wrapping new kernel. You can take the sources of a pretty old windows program and with minimal or no modifications you have good chances to compile it even for a 64 bit system. I think this backward compatibility drains a lot of their energy and it implies some practical restrictions (like language).