Pelles C forum
Pelles C => Bug reports => Topic started by: Vortex on April 05, 2014, 11:25:47 PM
-
First of all, many thanks to Pelle for this new release.
Trying to install Version 8.00 RC1 32-bit on my Windows XP installation, I received the error message below :
Windows Vista, Windows 7, or Windows 8 required; the setup will now exit.
I was able to install RC1 on a Windows 7 PE environment and they copy the Pelles C folder to my XP system. Except poinst.exe, the IDE and tools are running on Windows XP.
-
XP is no longer listed as supported platform on the download page of v8.
This seems to be feasible as XP is dropped this month by Microsoft.
-
The question is legal.
The setup shows XP as allowed OS
-
Except poinst.exe, the IDE and tools are running on Windows XP.
Which means everything will be fine soon, just wait that Pelle finds the one line in poinst.c that depends on a Vista+ function.
-
When we speek " For Windows 32 ", we mean for Win2K and then.
Also I like more WinXP 32 bits than WinVista 32.
If MS stopped supporting WinXP, it is up to them.
But we want a good C compiler for win 32 and 64, not to buy a new OS.
I always program for Win2K and then.
If I can not use PelleC, I 'll turn into MS compilers.
Manos.
-
If I can not use PelleC, I 'll turn into MS compilers.
We'll miss you.
-
We'll miss you.
Actually, will you personally miss me ?
Manos.
-
Extended support for XP ends in two days (April 8th) -- after that no more security updates and patches. It sounds like a bad idea to continue using XP...
...but I don't think there are any huge technical reasons for removing it. OpenMP will probably not work well, but everything else should.
So, with this in mind, should I re-enable support for XP ?!
-
Hi Pelle,
Including me, a lot of coders are using the good old Windows XP. We would be grateful for your decision to support XP.
-
Extended support for XP ends in two days (April 8th) -- after that no more security updates and patches. It sounds like a bad idea to continue using XP...
...but I don't think there are any huge technical reasons for removing it. OpenMP will probably not work well, but everything else should.
So, with this in mind, should I re-enable support for XP ?!
But your compiler is not an XP support, is a great tool that covers many many platforms ;)
-
Extended support for XP ends in two days (April 8th) -- after that no more security updates and patches. It sounds like a bad idea to continue using XP...
...but I don't think there are any huge technical reasons for removing it. OpenMP will probably not work well, but everything else should.
So, with this in mind, should I re-enable support for XP ?!
In the sense that technology has moved on .. No.
But then still having 14,000,000 users world wide is very impressive.
-
I always program for Win2K and then.
If I can not use PelleC, I 'll turn into MS compilers.
The MS compilers don't support Win2k for some time now.
The last one was the compiler included with WinSDK 6.0, the Win7 SDK is not supporting Win2k either.
-
I always program for Win2K and then.
If I can not use PelleC, I 'll turn into MS compilers.
The MS compilers don't support Win2k for some time now.
The last one was the compiler included with WinSDK 6.0, the Win7 SDK is not supporting Win2k either.
Not entirely correct... The function calls from the Windows 2000 API are all still there... in fact a lot of the API hails from Windows 3.1. As long as a compiler can build 32 bit code, static links to the CRT and doesn't use any API calls that don't exist in Windows 2000 dlls it is still entirely possible to write programs that will run just fine on it.
Now, getting W2k drivers for new hardware... that's a challenge.
-
The MS compilers don't support Win2k for some time now.
The last one was the compiler included with WinSDK 6.0, the Win7 SDK is not supporting Win2k either.
I have in my PC WinXP sp2 and also a laptop with Win7 64 bits.
I have downloaded Windows Server 2003 Service Pack 1 (SP1)
Driver Development Kit (DDK) and the folder WINDDK includes the following subfolders:
Bin\x86, inc\atl21, inc\atl30, inc\crt, inc\ddk, \inc\mfc42, inc\w2k, \inc\wnet, inc\wxp,
lib\atl, lib\crt, lib\mfc, lib\w2k, lib\wnet, lib\wxp.
I have builded many projects in my PC, (WinXP), with VC++ 2005 express,
using inc\w2k and lib\w2k dynamically linking with MSVCRT.dll.
All projects run OK in my laptop, (Win7 64 bits).
Manos.
-
XP is no longer listed as supported platform on the download page of v8.
This seems to be feasible as XP is dropped this month by Microsoft.
Sorry, but that is simply not correct. M$ stops providing patches to the "general public" come April 8th. That's all. Nothing stops working with existing Windows XP setups and big corporations, who can afford it, are still provided with updates. For years to come...
Ralf
-
So, with this in mind, should I re-enable support for XP ?!
Sure! I haven't understood why the support for win2k was canceld with the last release.
If some new features need special os-support, that should be documented and than it is ok!
But the tool himself (ide, compiler, linker etc) should be useable by all of us, independent of os (>=w2k)!
It should be the decision of the software developer, which OS he/she supports. But it is not obvious how to use the MS-compiler in order to produce w2k-compatible (or xp-compatible) software and so most free software is not downwards compatible although it easily could be. It is annoying that the free software providers are pushing MSs business interests more than MS himself. And Pelles C should not do the same.
C is a programming language which doesn't boss the programmer around and so shouldn't a C programmers tool.
czerny
-
should I re-enable support for XP ?!
If it's not a lot of work, yes. My notebook is too old to install Win7 or Win8.
But then, Pelles C #7 is complete enough to continue coding with it in XP, therefore I wouldn't start crying if you decide to drop XP support.
-
C is a programming language which doesn't boss the programmer around and so shouldn't a C programmers tool.
Still running windows 2000, ain't ya?
We had this conversation a long time ago. There will come a day when you wil be left behind and I'm sorry to say it's going to be your own silly fault.
A lot has happened since W2k ... USB, SATA, IPUs, 5.1 audio, HD Video, terabyte hard disks, 100mips lan, gigabit lan, touchscreen, tablets, ipods... In this case it's OpenMP which microsoft supports only since Windows 7.
Trying to use OpenMP on either W2K or XP is going to cause you no end of grief because the OS cannot support it.
My suggestion to Pelle would be to re-enable W2K and XP support but to put a stern warning at install time about OpenMP --and a bunch of other stuff-- not working on those systems.
-
I agree with CommonTater.
Manos.
-
Still running windows 2000, ain't ya?
We had this conversation a long time ago. There will come a day when you wil be left behind and I'm sorry to say it's going to be your own silly fault.
Why not? I use a couple of different OSs in different situations. One of my customers is using a 486 with MS-DOS as operating system (controlling a measurement instrument). I use a scythe to mow my land and I use my head to calculate 652. Why not?
I only would like to use the right tool in a special situation.
In the old days turbo pascal uses processor switches to produce code for different processors.
Pelles C could use an OS switch like -os5 or -os5.2 or -os7 to set the minimum requirement for the actual project. So nobody has to deal with stern warnings.
czerny
-
Hi czerny,
CommonTater is right, it's not easy to combine new technologies with the old ones. You will often encounter serious incompatibility problems.
Windows XP has a large user base and there are a lot of companies using XP installations.
-
Windows XP has a large user base and there are a lot of companies using XP installations.
At this time! One year later ...
Its a matter of philosophy how to handle such cases. We all will be more and more driven by the market and lesser and lesser masters of our own decisions.
But this here is Pelles decision!
czerny
-
Its a matter of philosophy how to handle such cases. We all will be more and more driven by the market and lesser and lesser masters of our own decisions.
Very nicely said. Sad but true, this is a world of masters and slaves.
-
Windows XP has a large user base and there are a lot of companies using XP installations.
At this time! One year later ...
Its a matter of philosophy how to handle such cases. We all will be more and more driven by the market and lesser and lesser masters of our own decisions.
There are still tens of thousands of people using Windows 2000 ... in fact I still run into the occasional win98 box. But I think you misunderstand the problem here...
As I said before, the general CRT (C Run Time) library is not the problem. It can be statically linked which means that functions you use are copied right into your program. You can thus use a strictly C program from Pelles C 8.00 on a Windows 2000 system without worries.
The thing you have to be careful with is the Windows API... if you used functions that were included with Vista in your code, it's not going to run on an XP or Windows 2000 machine. You will get runtime errors telling you the functions don't exist. (Because, on that system, they don't).
This is why you will occasionally run into one of my libraries or addins that won't let you put it on a Win2000 machine... because, in order to get the desired functionality I had to use API calls that won't exist on your machine.
Of course the same problem exists with *every* piece of software currently out there. If they've used API calls that were first added for XP, Vista, 7 or 8, it's not going to run on your machine.
I agree this amounts to pressure to keep up... and to be honest I think that is a good thing. As I said before a lot of really good stuff has been invented and incorporated since Win2k.
Letting yourself fall behind by a couple of years is not likely to be a problem. Most programmers still write from the XP API, being fully aware that many of the newer functions are not present on those machines. However; slipping into a 15 year anachronism, in computer time, amounts to being positively medieval ... a true antique. Not only are you not going to be able to update your software, there are many things you simply cannot do... like flashdrives, external hard disks and a whole lot more.
Including OpenMP in PellesC is something of a departure. The complication is that it requires both hardware and OS support. So for you the simple answer comes down to one compiler flag you cannot use. You wanted compiler flags, there you have it...
But this here is Pelles decision!
Yes it is. I would have chosen otherwise but I'm not the boss. Implementing something like OpenMP shold be a function for an extra library, not part of the core compiler. But it is there and it's not a bad thing... so I don't see any problem using it.
As I said above... I see no problem for Pelle to Re-Enable XP and Win2000 support so long as he is careful to warn his users not to enable certain features on older systems.
Better still... POIDE could check the OS version and disable those flags from it's projects as a form of idiot proofing.
-
I was able to install RC1 on a Windows 7 PE environment and they copy the Pelles C folder to my XP system. Except poinst.exe, the IDE and tools are running on Windows XP.
I don't think there are any huge technical reasons for removing it.
Apparently, only the installer uses non-XP code. If that can be fixed easily, it would be a GoodThingTM simply because there are forum members (not me) who earn a living with coding for older platforms. In some years, no other compiler will be able to support this market niche.
-
I was able to install RC1 on a Windows 7 PE environment and they copy the Pelles C folder to my XP system. Except poinst.exe, the IDE and tools are running on Windows XP.
I don't think there are any huge technical reasons for removing it.
Apparently, only the installer uses non-XP code. If that can be fixed easily, it would be a GoodThingTM simply because there are forum members (not me) who earn a living with coding for older platforms. In some years, no other compiler will be able to support this market niche.
Far more likely the installer is blocking the installation because the toolchain is using non-XP code.
If I had a monster package that had one function call to an API that does not exist in XP, I would block the installation rather than risk messing up a customer's data.
It's totally about precaution.
-
Very nicely said. Sad but true, this is a world of masters and slaves.
http://en.wikipedia.org/wiki/Spartacus (http://en.wikipedia.org/wiki/Spartacus)
-
The thing you have to be careful with is the Windows API... if you used functions that were included with Vista in your code, it's not going to run on an XP or Windows 2000 machine. You will get runtime errors telling you the functions don't exist. (Because, on that system, they don't).
We know that! But an -os5 switch could help to avoid such problems buy giving a warning or an error during the build process.
-
The thing you have to be careful with is the Windows API... if you used functions that were included with Vista in your code, it's not going to run on an XP or Windows 2000 machine. You will get runtime errors telling you the functions don't exist. (Because, on that system, they don't).
We know that! But an -os5 switch could help to avoid such problems buy giving a warning or an error during the build process.
You don't seriously expect Pelle to issue compiler warnings for Windows API functions... Seriously... just check the functions before you use them. 4 of 5 times when I use a Windows API function I have to look it up in the Windows SDK help anyway, and the information is right there at the bottom of every page.
-
_WIN32_WINNT ;)
Not a big help ... lets say you're on a windows 7 machine and you write some code that works outright perfectly ... now you give a copy to an XP user and he's getting system errors galore... because API calls that do exist on your system do not exist on his.
Best bet... decide on a "minimum OS version", write for that being minful of the functions you use and check the Windows Version when your program (or installer) starts up. If it doesn't meet the requirement, exit to the OS with a warning.
#ifndef _WIN64
// check version -- Win2k or newer required
VOID CheckWindowsVersion(void)
{
OSVERSIONINFOEX os = {0}; // version information
DWORDLONG cm = 0; // conditioning value
// precondition struct
os.dwOSVersionInfoSize = sizeof(os);
os.dwMajorVersion = 5;
os.dwMinorVersion = 0;
os.wServicePackMajor = 0;
// condition the results
VER_SET_CONDITION(cm,VER_MAJORVERSION,VER_GREATER_EQUAL);
VER_SET_CONDITION(cm,VER_MINORVERSION,VER_GREATER_EQUAL);
VER_SET_CONDITION(cm,VER_SERVICEPACKMAJOR,VER_GREATER_EQUAL);
// exit on older versions
if (!VerifyVersionInfo(&os,VER_MAJORVERSION | VER_MINORVERSION |
VER_SERVICEPACKMAJOR,cm))
{
wprintf(L"Windows 2000 or newer required for this program\n\n");
exit(0);
}
}
#endif
http://msdn.microsoft.com/en-us/library/windows/desktop/ms725492(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms725492(v=vs.85).aspx)
-
In some years, no other compiler will be able to support this market niche.
Yep!
I think it's on the programmer his self to decide which functions he use are compatible or not to the various os. Is there a serious reason to drop xp support in v8? Then drop it! If not, then let it by supporting xp. It could be a feature for people who run their old xp, looking for a modern c compiler with a nice small and fast ide on old hardware. And please also keep in mind the discussion here on the domain about the ms headers and the restrictions which result from the lack of compatibility with the ms c++ definitions. Better gaining people than loose them in competition.
By the way, what does pelle personally think about rewrite the headers? This is a question for the future of pelles c in the c compiler market too.
a) no way
b) why not, but it's a huge task and it need a lot of time (which I don't have).
c) soon after I released v8
What does pelle think?
-
_WIN32_WINNT ;)
Not a big help
Look here (http://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx) and here (http://=http//msdn.microsoft.com/en-us/library/6sehtctf.aspx)
Yes, I know that... but it still won't stop czerny from trying to use a program compiled for Win7 on his antique OS... You need a version check like I described to block installation if you are using any post version apis...
For example:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364422(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa364422(v=vs.85).aspx)
Look closely at the bottom of the page... Minimum OS Version == Vista.
If you use FindFirstFileTransacted() in your project and someone tries to run it on Win2k or XP it's gonna crash... Nearly 500 new API calls have been added since XP.
Setting WIN32_WINNT to windows 2000 is not going to make that function magically appear in the Win2k DLLs... Hense the need for that install time or run time check.
-
You can always use an older release of Pelles C for an outdated Windows release.
I don't see a point in beating a dead horse (also known as Win2k) or one that is fading out (also known as WinXP).
Development should be simple, so why make your code more complicated than needed just to support ancient Windows releases.
Do you really like to add numerous compiler directives to create multiple executables from one source?
Why shouldn't I use the new API function introduced in newer Windows releases, just to keep a fading user base happy?
Come on guys, who is still using a typewriter to develop computer software?
Do what you like, but don't hinder Pelle getting into the next step of developing a future-prove IDE.
Food for thought, no offense intended ;)
-
You can always use an older release of Pelles C for an outdated Windows release.
Do what you like, but don't hinder Pelle getting into the next step of developing a future-prove IDE.
No need to go to an older release... just be mindful of the Windows API calls. It's really not a big deal, just some well planned programming. Nobody is forcing anyone to update anything.
I doubt Pelle is hindered by any of this... in fact I'm betting he's having a good chuckle over it, 'cause it is kinda silly.
-
but it still won't stop czerny from trying to use a program compiled for Win7 on his antique OS...
You don't want to understand!
I do not want to use a win7 program on a w2k machine as a software user!
I want to use a compiler as a programmer to build software for any os!
-
You don't want to understand!
I do not want to use a win7 program on a w2k machine as a software user!
I want to use a compiler as a programmer to build software for any os!
Well, maybe let's limit it to Windows versions ;-)
Somebody wrote that we need to move on, and use the thousands of new API functions like FindFirstFileTransacted [Microsoft strongly recommends developers utilize alternative means to achieve your application’s needs. Many scenarios that TxF was developed for can be achieved through simpler and more readily available techniques. Furthermore, TxF may not be available in future versions of Microsoft Windows. For more information, and alternatives to TxF, please see Alternatives to using Transactional NTFS.]
The point is, you are absolutely free to do so. Like I am absolutely free to invoke this function in assembly, using MASM32 with version 6.14:
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
We must distinguish between the tool (Pelles C, MASM) and what we do with the tool.
The tool reads headers and code and spits out executables. We write headers and code. If I need a brand new exotic Win 8.1 function with my 1997 version of MASM, I use Erol's tools to extract a lib from System32\xyz.dll, write ExoticFunction PROTO :DWORD, :DWORD into a textfile, and feed that to my trusty assembler - bon appetit.
As far as I can see, the only really big obstacle for doing so is that the installer of the latest release candidate of Pelles C uses one or two of these exotic functions that Microsoft added after XP...
-
but it still won't stop czerny from trying to use a program compiled for Win7 on his antique OS...
You don't want to understand!
I do not want to use a win7 program on a w2k machine as a software user!
I want to use a compiler as a programmer to build software for any os!
Trust me, I understand perfectly...
But you will not be able to run or test a program written using Win7 API calls on Win2000 ... it will crash because the calls do not exist on your computer.
You can not write new stuff from an antique OS...
but you can write antique stuff from a new os.
Understand this... Windows API calls like FindFirstFileTransacted() are NOT part of Pelles C. They are not statically linked into your programs. They are housed in DLLs supplied with your operating system. Yes you can include the header and it will validate the call for the compiler. Yes you can link to the .lib and it will provide the linker's reference to the DLL ... BUT unless that function actually exists in the DLL, your program is going to crash at runtme.
Working from win2k you cannot write any program for any system newer than Win2k, you will not be able to test it as it will crash on your own system.
Working from (say) Win7 would allow you to build for 2000, 2003, XP, 2008, Vista, and Win7. All you need to do is be mindful of the API functions you call.
You, my friend, have it backwards.
-
Somebody wrote that we need to move on, and use the thousands of new API functions like FindFirstFileTransacted
NOBODY said that JJ ... please work on your literacy skills.
What I did say was that if he wants to use those functions he needs to update his OS because those functions do not exist in the DLLs of windows 2000.
The point is, you are absolutely free to do so. Like I am absolutely free to invoke this function in assembly, using MASM32 with version 6.14:
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
The point is that you CANNOT do that. Yes you can invoke anything you want in assembler... but if the function does not exist on your operating system... guess what happens...
The tool reads headers and code and spits out executables. We write headers and code. If I need a brand new exotic Win 8.1 function with my 1997 version of MASM, I use Erol's tools to extract a lib from System32\xyz.dll, write ExoticFunction PROTO :DWORD, :DWORD into a textfile, and feed that to my trusty assembler - bon appetit.
My god are you not getting any of this?
1) This is a C forum, nobody here gives a rats wrong end about assembler.
2) No you cannot link to a function that does not exist on your operating system.
We're not talking about libs and headers... the question is does the function you imported exist in the DLLs of a given operating system.
The function "FindFirstFileTransacted" Does Not exist in the Windows 2000 version of kernel32.dll ... it's simply not there... trying to call it will crash your program.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364422(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa364422(v=vs.85).aspx)
As far as I can see, the only really big obstacle for doing so is that the installer of the latest release candidate of Pelles C uses one or two of these exotic functions that Microsoft added after XP...
Oh, you mean things like OpenMP?
OpenMp was adopted by Microsoft with Vista. So the whole sub-category is useless on anything before Vista. Why is this so hard to understand?
-
Trust me, I understand perfectly...
No, you do not understand!
We are talking about the tool, an IDE and don't want any limitations with this tool.
We all are able to decide which OS to use to write a certain programm. Sometimes I use win2k, to be sure to be downwards compatibel.
czerny
-
Trust me, I understand perfectly...
No, you do not understand!
We are talking about the tool, an IDE and don't want any limitations with this tool.
We all are able to decide which OS to use to write a certain programm. Sometimes I use win2k, to be sure to be downwards compatibel.
czerny
Oh boy ... this is getting really stupid.
We've had this conversation before and you have repeatedly demonstrated a very low comprehension of why some things are not supported.
In particular you took to making bug reports about my addins just because they did not work on windows 2000, arguing stenuously that I had to do this just for you. Let me remind you there are incompatibilities in the visual experience between windows 2k and XP, some things cannot work in both places without extensive version awareness and all that does is bloat the hell out of the code.
Nothing says Pelle has to continue writing a windows 2000 compatible IDE **just for your convenience**. Once again, there are things he can do in more advanced systems that cannot be done on windows 2000 ... Why would you seek to prevent Pelle from incorporating these features into his IDE?
Technology is moving along and you are 15 years behind the times.
My friend, it's time to either grow up or give up.
mods.... This subject is not and never was about a valid bug report. It should be either locked or moved.
-
Oh boy ... this is getting really stupid.
I am not a boy and this conversation is really stupid indeed. So I will stop it!
-
Oh boy ... this is getting really stupid.
I am not a boy and this conversation is really stupid ideed. So I will stop it!
Friend, no need to get offended. Tator's comment did not refer to you personally. It is rather simply a figure of speech used as an expression of dismay, resignation, frustration, or annoyance (sarcastic). (http://en.wiktionary.org/wiki/oh_boy)
I always find in these situations it is best to cut each other some slack and let the matter pass.
-
Oh boy ... this is getting really stupid.
I am not a boy and this conversation is really stupid ideed. So I will stop it!
Friend, no need to get offended. Tator's comment did not refer to you personally. It is rather simply a figure of speech used as an expression of dismay, resignation, frustration, or annoyance (sarcastic). (http://en.wiktionary.org/wiki/oh_boy)
I always find in these situations it is best to cut each other some slack and let the matter pass.
I have a better solution ...
I see nothing here that is helping anyone with Pelles C.
The suggestion that we update the Windows API resulted in two of the most long term users jumping into "show off" mode: "See I can make it work. All I have to do is ignore thousands of warnings." It did absolutely nothing to organize an attempt at contributing new functionality to Pelles C nor did it manage to update a single header. Well, done!
JJ2007 seems to think that posting ASM code makes him look smarter than us and he's splattering simple questions with complex ASM sequences that do nothing but confuse the person asking. Beginners need simple answers relevent to C coding... JJ has admitted to never written a single program in C... yet he's still here confusing the hell out of the newbies while doing nothing better than showing off.
czerny continues to misunderstand, clinging to an anachronism and lecturing people about their need to support him. Well the short answer is no we don't have to do that if he can't keep up, that's his problem not ours.
Suddenly we are giving users personal platforms to tout their own software. The new "projects in pelles c" forum is both redundent and counterproductive. The simple reason being that very few people actually write projects in Pelles C. Over the years I've only seen my stuff and ultradefrag mentioned here.
The moderators here are inert. Sometimes I wonder how their brains generate enough energy to get them typing. This forum is not policed in any meaningful way and a lot of people have commented on other forums that nothing helpful ever happens here. The most common complaint? "A noob cannot come here and get a simple answer to a simple question... "
Because of all this Pelles C is one of two things... a first tool for absolute beginners or an excellent tool for experienced programmers writing console programs. Beyond that it's use is very limited.
Pelle had all the right ideas. A standards compliant fully capable C coding system for console and gui programs... excellent idea and well put together... but the users who've gathered around it simply don't get behind the project and support it. Some have even argued that we should not tamper and use it only "as is"... what a ludicrous assertion!
So the forums sit mostly quiet. The software is largely regarded as a beginners tool. AND... I don't see this changing anytime soon.
I can now see that I made a mistake coming back here ... a mistake I will not repeat.
-
This forum is not policed in any meaningful way and a lot of people have commented on other forums that nothing helpful ever happens here. The most common complaint? "A noob cannot come here and get a simple answer to a simple question... "
I wouldn't say so. I think this forum is a good place to look at for everyone who is interesseted yet in the win32 programming although users today often prefer one of the big c++ frameworks like qt or the ms c# .net framework.
Because of all this Pelles C is one of two things... a first tool for absolute beginners or an excellent tool for experienced programmers writing console programs. Beyond that it's use is very limited.
I think there is nothing wrong with pelles c if it is an excellent tool for beginners in the c lang. Because it is not a c++ compiler, you can not prevent the more experience users to switch in the course of time to one of the big c++ tool frameworks.
I can now see that I made a mistake coming back here ... a mistake I will not repeat.
Just do not expect too much and do not so hot get stuck in to the matter. Cool down!
;)
-
yada, yada, yada.
As I said else-thread, I will remove the block in the 32-bit setup for Windows XP in RC2 - but I will not officially support XP, test on XP, accept bug reports relating to XP, etc. IIRC, the support for multiple cores on Windows XP is either poor or missing - OpenMP is unlikely to work well/at all. And so on, and so on.
-
As I said else-thread, I will remove the block in the 32-bit setup for Windows XP in RC2 - but I will not officially support XP, test on XP, accept bug reports relating to XP, etc. IIRC, the support for multiple cores on Windows XP is either poor or missing - OpenMP is unlikely to work well/at all. And so on, and so on.
Very nice decision.
Thank you,
Manos.
-
Hi Pelle,
Many thanks.