Pelles C forum
Pelles C => Bug reports => Topic started by: czerny on May 08, 2012, 01:54:27 PM
-
Try to build this library project and look at the error message. It is not readable.
-
I get....
Building logview.lib.
POLIB: fatal error: File not found: 'Shlwapi.lib'.
*** Error code: 1 ***
Done.
If I remove shlwapi.lib from the librarian's options, it builds just fine.
If you #define WIN32_DEFAULT_LIBS before you #include any of the windows headers Pelles C will automatically include the correct libraries for you. Very handy.
-
PellesC shouldn't bark at the shell lightweight API library, since it is shipping with PellesC for x86 and x86-64.
Haven't checked the projects library paths, but that might cause the problem.
-
Lock at this picture, to understand what I mean.
-
Use the attached project.
I found in the library manager that you set to include the shlwapi library in your library.
If you intentionally added it that was the error, if not there is a problem in the library wizard.
-
This module is part of a bigger project which builds without errors. The included lib is not the problem, see picture.
-
But you don't have to include it here!
Look at the picture....
-
But you don't have to include it here!
Look at the picture....
Hallo Frankie,
see my last post.That's not the point.
-
Ok, from the command line I can not run polink. I get 'not a valid win32 application'.
-
Ok, from the command line I can not run polink. I get 'not a valid win32 application'.
You aren't by any chance trying to build a 64 bit application from 32 bits Windows, are you?
32 bit OS does not recognize and will not run 64 bit programs...
Could you perhaps have mixed up the versions or something?
My suggestion would be to uninstall, reinstall and try this again...
-
I have just reinstalled Pelles C. I have compared the two polib.exe files (md5). The two are identical. The problem remains.
I fear that Pelle uses a new Microsoft Compiler. I have seen a lot of free software which does not longer run under win2k if compiled with the new Visual Studio 10. I wonder why the other tools are running?
-
I have just reinstalled Pelles C. I have compared the two polib.exe files (md5). The two are identical. The problem remains.
I fear that Pelle uses a new Microsoft Compiler. I have seen a lot of free software which does not longer run under win2k if compiled with the new Visual Studio 10. I wonder why the other tools are running?
Sorry, but I seriously doubt that!!!!
Even though he doesn't provide the source code, I am pretty sure that Pelle's C is self-hosting for a long time, simply no need/purpose in using any MS compiler...
Ralf
-
I have just reinstalled Pelles C. I have compared the two polib.exe files (md5). The two are identical. The problem remains.
I fear that Pelle uses a new Microsoft Compiler. I have seen a lot of free software which does not longer run under win2k if compiled with the new Visual Studio 10. I wonder why the other tools are running?
Everything works here... CL and in projects. The 32 bit version works on my XP box as well...
If there was a problem with 32bit POLIB I'm guessing the hue and cry would be up and going by now...
Maybe it's finally time for you to update that antique machine of yours... XP with sp3 will probably work with your current hardware and will most likely work with a LOT more software than Win2k...
-
If there was a problem with 32bit POLIB I'm guessing the hue and cry would be up and going by now...
+1
And as I mentioned before, it is highly doubtful that Pelle uses anything bu this own compiler for this....
Maybe it's finally time for you to update that antique machine of yours... XP with sp3 will probably work with your current hardware and will most likely work with a LOT more software than Win2k...
Which legally isn't an option anymore... ;)
But I doubt that this is a problem with the OS he's running on, I suspect rather a subtle issue elsewhere that's just happen to rear it's ugly head after the latest update of Pelle's C....
Ralf
-
Ok, from the command line I can not run polink. I get 'not a valid win32 application'.
Seems that the PE header contains a higher target release than W2k allows.
-
From the polib pe header:
linker version 10.00
required OS version 5.01
subsystem version 5.01
-
Well, it is quite possibly a bug in POlib, but nothing with "broken" error message or using a specific compiler. It seems to be a pathname problem.
Include the full path to shlwapi.lib into the Library Manager's command line and it will compile just fine....
Ralf
-
Ralf
it is not a pathname problem. Have you seen the error message at the pictures I have posted?
Polib.exe didn't start at the command line at all.
czerny
-
Ralf
it is not a pathname problem. Have you seen the error message at the pictures I have posted?
Polib.exe didn't start at the command line at all.
czerny
That's not what your screenshots show and I could only reproduce (on XPSP3 32bit) the same error as CommonTater. I do not have a Windows 2000 machine around here right now, I will check with that later today, if time permits...
Ralf
-
If there was a problem with 32bit POLIB I'm guessing the hue and cry would be up and going by now...
+1
And as I mentioned before, it is highly doubtful that Pelle uses anything bu this own compiler for this....
I would expect so as well... The best test of a compiler is for it to compile itself. The second best test is for it to compile it's own libraries.
Maybe it's finally time for you to update that antique machine of yours... XP with sp3 will probably work with your current hardware and will most likely work with a LOT more software than Win2k...
Which legally isn't an option anymore... ;)
Actually it is... czerny has said he has a copy of XP he purchased but never used.
You can download SP3 for free from... HERE (http://www.microsoft.com/en-us/download/details.aspx?id=24)
But I doubt that this is a problem with the OS he's running on, I suspect rather a subtle issue elsewhere that's just happen to rear it's ugly head after the latest update of Pelle's C....
Maybe so...
-
From the polib pe header:
linker version 10.00
required OS version 5.01
subsystem version 5.01
OOPS... That's not going to work on Win 2000 which is version 5.00 ...
Windows version details ... HERE (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724834(v=vs.85).aspx)
To view the version of your OS... open a command shell and type winver and hit enter.
EDIT: It would be nice if Pelle could clarify if this is a point of necessity for his code, or an error in setting version data.
-
Ok, I went ahead and installed Pelle's C 7.00.3 (RC2) 32bit on a Windows 2000 machine.
In fact, there are 3 files in the bin folder that won't run as provided on Windows 2000: poinst.exe, polib.exe and pomc.exe, all have a minimum OS version of 5.1 (Windows XP) in their PE header.
However, using PE_PATCH (http://thesz.diecru.eu/content/pe_patch.php), I changed this in polib.exe to 4.0 as in all other executables, and it will run in Windows 2000 with the provided project file, given that the path is corrected as I stated before...
Ralf
-
Ok, I went ahead and installed Pelle's C 7.00.3 (RC2) 32bit on a Windows 2000 machine.
In fact, there are 3 files in the bin folder that won't run as provided on Windows 2000: poinst.exe, polib.exe and pomc.exe, all have a minimum OS version of 5.1 (Windows XP) in their PE header.
However, using PE_PATCH (http://thesz.diecru.eu/content/pe_patch.php), I changed this in polib.exe to 4.0 as in all other executables, and it will run in Windows 2000 with the provided project file, given that the path is corrected as I stated before...
Ralf
That's good news ... but it also raises a concern...
I can't speak for how Pelle does things, but when I program something I always set the version resources (etc) to the oldest OS that will work. Quite often that ends up being XP-SP1 because I've had to use a system call that didn't exist before then... Now if Pelle uses a similar tactic, it may well be that it ran *this time* but may crash when it tries to call some Windows API function that doesn't exist in Windows 2000...
If it works, that's great... but I would caution czerny to test this VERY carefully before he trusts it...
-
Ok, I went ahead and installed Pelle's C 7.00.3 (RC2) 32bit on a Windows 2000 machine.
In fact, there are 3 files in the bin folder that won't run as provided on Windows 2000: poinst.exe, polib.exe and pomc.exe, all have a minimum OS version of 5.1 (Windows XP) in their PE header.
However, using PE_PATCH (http://thesz.diecru.eu/content/pe_patch.php), I changed this in polib.exe to 4.0 as in all other executables, and it will run in Windows 2000 with the provided project file, given that the path is corrected as I stated before...
Ralf
That's good news ... but it also raises a concern...
I can't speak for how Pelle does things, but when I program something I always set the version resources (etc) to the oldest OS that will work. Quite often that ends up being XP-SP1 because I've had to use a system call that didn't exist before then... Now if Pelle uses a similar tactic, it may well be that it ran *this time* but may crash when it tries to call some Windows API function that doesn't exist in Windows 2000...
If it works, that's great... but I would caution czerny to test this VERY carefully before he trusts it...
Nowhere is mentioned that Pelle's C 7.0 is officially supporting Windows 2000, it clearly states XP/Vista/7. Only for 6.x, it lists Windows 2000 (2k) explicitly, so czerny is pretty much on it's own from the get go...
I don't claim that patching the executable this way is a general solution, I just gave it a quick try and at least in this case, it seems to work.
And all other, more essential tools than polib.exe, are in fact working fine, having "4.0" as their minimal OS listed. No idea why just those 3 are different...
Ralf
-
Ok, I went ahead and installed Pelle's C 7.00.3 (RC2) 32bit on a Windows 2000 machine.
In fact, there are 3 files in the bin folder that won't run as provided on Windows 2000: poinst.exe, polib.exe and pomc.exe, all have a minimum OS version of 5.1 (Windows XP) in their PE header.
However, using PE_PATCH (http://thesz.diecru.eu/content/pe_patch.php), I changed this in polib.exe to 4.0 as in all other executables, and it will run in Windows 2000 with the provided project file, given that the path is corrected as I stated before...
Ralf
And all these exes arel linked by an other linker (10.0).
-
What I like on the C language is, that it does not patronize me, that I have full control.
I wish, the same could be true for my compiling tools. Thats why I am using Pelles C. This toolset lets me compile even win95 programs (I sometimes need to support ME). Though it would be better it would me allow to create even 16-bit dos code (what I need more often).
M$'s strategie is to give there free tools to kick off unwanted oses. And this works and undermines the free software idea.
Look here (http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/e89c93e7-1db2-4d88-b834-d8157b4b971b)
I see a lot of it professionals discussing for hours how to argue their toolset (VS2010) to support windows 2000. They need not any XP functions.
I doubt that there is some functionality needed to compile Pelles C 7.0 which can only be found in XP and above. Now then why not include win2k?
But it is Pelles decision (or the decision of his toolset) if he want to include it or not.
If the later is the case, then it would be nice if we could get a final 6.5 version where the known bugs are fixed.
czerny
-
In all due respect, my friend, you've caught yourself in a time warp and now it's starting to catch up to you.
You've moved on to a compiler/etc setup that postdates your Operating System by more than a decade. The Winodws Libraries and Headers appear to correspond most closely with Vista... and this means there are bucketloads of stuff in them that will compile/link quite happily and then crash like crazy on your operating system, because the underlying DLL code simply isn't there.
You will also begin to find tools, like POLIB, that won't even run on your old OSs... 64 bit Windows won't even run 16 bit code anymore and version lockouts are becomming more and more common. None of my software (even the free stuff) will run on any OS before XP-SP1 since most of it us using API calls that simply didn't exist before then, so I block them to prevent crashes.
It would seem that your problem with my AddIn was merely the first sign of things to come and it's bound to get continually worse for you as time goes on. In fact, it's even starting to happen with XP users... as quite a number of Vista/7 only apps are now out there... Windows 8 will make it a lot worse since the UI has been substantially trashed reworked.
The thing is that when you are working with antique systems you really should be working with headers and libraries that closely match that version of the OS and in this case that means you probably should be working with Pelles C 3 or 4, certainly not 7. (You can get older versions... HERE (http://www.pellesc.de/index.php?page=start&lang=en) )
In nothing more than a sincere desire to help you, I do have to wonder why on earth you are so horridly opposed to updating your systems.
I understand from our past conversations that you have a long series of softwares installed that you don't want to have to reinstall... and I'm guessing it's because you don't have the distributions of the software. Thing is with a new OS you would likely discover newer versions of the same software or other packages that do the same things for you. Except this time... you need to archive the distributions away on an external hard drive or DVDs so you have them in case you need to reinstall.
XP is very flexible. It was meant to heal the wound ME caused and it will run on almost any 32 bit PC. It is also the most compatible with Linux Wine. There are tons of drivers out there and most hardware manufacturers are still updating for XP. Most freeware and shareware still runs fine on XP (I've only run into one problem, with a Codec, and it took me about 6 seconds to find an XP compatible version). Literally anything that works on 95, 98, ME, 2000 is going to work on XP... it can also use win2000 drivers.
All this began with your objection to my use of "Visual Styles"... I'm sorry to be blunt, but that's a terrible reason to not update your systems. They can be turned off with nothing more than unchecking a box in the System -> Performance -> Advanced dialog. From there, XP looks just like Win2000... except it doesn't crash when it encounters controls that use VS.
Your problem is only going to get worse with time and I'm thinking all your excuses not to update your systems have pretty much evaporated.
-
In all due respect, my friend, you've caught yourself in a time warp and now it's starting to catch up to you.
You are right in this and I know that I have to update.
You've moved on to a compiler/etc setup that postdates your Operating System by more than a decade. The Winodws Libraries and Headers appear to correspond most closely with Vista... and this means there are bucketloads of stuff in them that will compile/link quite happily and then crash like crazy on your operating system, because the underlying DLL code simply isn't there.
You will also begin to find tools, like POLIB, that won't even run on your old OSs... 64 bit Windows won't even run 16 bit code anymore and version lockouts are becomming more and more common. None of my software (even the free stuff) will run on any OS before XP-SP1 since most of it us using API calls that simply didn't exist before then, so I block them to prevent crashes.
Here you are not right.
I do not need any function which only exist in XP and above. But I like to write software which runs under xp and above TOO. It should be in the responsibility of the programmer which functions to use. So with POLIB. Is there a function missing in win2k needed to compile POLIB? I question that.
All this began with your objection to my use of "Visual Styles"... I'm sorry to be blunt, but that's a terrible reason to not update your systems.
Oh no. That's not the reason.
I am as obstinate as I am, because this game will go on in few years with XP, because we are not the doers, we are other-directed by commercial interests. But once more, you are right, it is silly to insist on this. I will buy a quicker machine and update.
-
You've moved on to a compiler/etc setup that postdates your Operating System by more than a decade.
Here you are not right.
I do not need any function which only exist in XP and above. But I like to write software which runs under xp and above TOO. It should be in the responsibility of the programmer which functions to use. So with POLIB. Is there a function missing in win2k needed to compile POLIB? I question that.
The problem with this approach is that you can't TEST software under those conditions. If you are incorporating code that uses API calls that don't exist on your system, it is literally impossible for you to test it since it will just crash on your machine. So, what you end up doing is writing code that works on your system and then counting on "backwards compatibility" in other systems to see it work. Mostly this is OK, but as you've seen there are many cases where it does come back to bite you... Worst case, you are releasing untested code.
I am as obstinate as I am, because this game will go on in few years with XP, because we are not the doers, we are other-directed by commercial interests. But once more, you are right, it is silly to insist on this. I will buy a quicker machine and update.
The whole world is directed by commercial interests... rebelling against that in such a way that you are the only person affected really doesn't make a lot of sense.
Before you go spending a bunch of money on hardware... try installing XP on your existing system. Really... if Win2000 runs, XP will most likely work as well... Heck, my cousin's got XP installed here on an old Penitum 3 machine his kid uses to do homework...
-
I think it is a problem with the sub-system version, since our executables are compiled for Windows 2003 and are still working on Windows NT 4.0 (see attached images).
@Ralf, sad that the PE patcher is a 16-bit application and doesn't support 64-bit executables ;)
-
I have installed PellesC 7.0 RC2 on Windows 2000 SP4, patched the above mentioned executables to be valid for sub-system 4.0 and removed the shlwapi.lib from the library manager to succeed building the project on Win2k.
The problem with backwards compatibility is to either use only the API functions of the lowest supported O/S version or to dynamically load DLLs at runtime.
Both ways just make your code complex, since there might be newer API functions that are much simpler or you need to code two ways to accomplish a task.
This is one reason why release 6.0 of UltraDefrag will support only WinXP and above.
Another reason for this are the enhancements in the defragmentation API compared to WinNT and Win2k.
@czerny,
From personal experience I would suggest to create a release of your software which has all reported problems fixed and doesn't add any new feature.
For the next major release drop support for Win2k and below.
I would virtualize your current system, so you can use your ancient tools on the new system too inside a virtual machine.
My setup is Windows 7 x64 as my main system and Win2k, WinXP, Vista and Win7 all x86 as virtual testing systems.
Allows to test all the old and new stuff ;)
-
Both ways just make your code complex, since there might be newer API functions that are much simpler or you need to code two ways to accomplish a task.
This is one reason why release 6.0 of UltraDefrag will support only WinXP and above.
Another reason for this are the enhancements in the defragmentation API compared to WinNT and Win2k.
I don't doubt that there are reasons to use some of the newer api functions and that it is difficult or impossible to do the same task with the old functions. New hardware support is a good example. But I am talking from software which is not useable because the PE header didn't allow its use.
From personal experience I would suggest to create a release of your software which has all reported problems fixed and doesn't add any new feature.
For the next major release drop support for Win2k and below.
I would virtualize your current system, so you can use your ancient tools on the new system too inside a virtual machine.
My setup is Windows 7 x64 as my main system and Win2k, WinXP, Vista and Win7 all x86 as virtual testing systems.
Allows to test all the old and new stuff ;)
Yes this sounds good. I have sniffed on this a few days ago with Frankie:
http://forum.pellesc.de/index.php?topic=4348.msg16750#msg16750 (http://forum.pellesc.de/index.php?topic=4348.msg16750#msg16750)
-
@Ralf, sad that the PE patcher is a 16-bit application and doesn't support 64-bit executables ;)
What could possibly be the purpose for that be? ::)
Ralf
-
I don't doubt that there are reasons to use some of the newer api functions and that it is difficult or impossible to do the same task with the old functions. New hardware support is a good example. But I am talking from software which is not useable because the PE header didn't allow its use.
A good example of this can be found in the Winsock2 subsystem where GetAddrInfo() and GetNameInfo() are used instead of the older gethostbyname() and gethostbyaddr() functions which do not work with unicode. And most programming these days is unicode. If I use the newer apis I have to block older OSs that won't have them.
It is entirely possible there is one call, perhaps even a seldom used one, in each of the programs that required this to avoid crashing... The only person who will know for sure is Pelle...
Of course there are many other examples and trying to support everything just isn't possible anymore.
As a programmer you make decisions about the likelihood of not supporting (say) win98 seriously affecting your product's market penetration... if the difference is miniscule and you can write better code, it's often smarter to dump the older systems *especially* since almost nobody will be using them anyway. The most proximate example of this is the thing about my C++ addin's settings dialog... I made a judgement call, not expecting any programmer to still be using Win2000...
Another aspect of this will also rear it's head eventually... The API is becomming so bloated with multiple versions of things, unused function calls, deprecated functions, etc. that eventually Microsoft will be forced to "clean house" and remove a lot of older functions... some of which you might be using for backward compatibility.
This is just my opinion --and it might make an interesting discussion in the appropriate forum-- but I don't see much point in deliberately supporting anything older than 3 generations. Currently... Win7, Vista, XP... Anything older is so unlikely to be in regular use that the time involved is not justified by the audience size.
-
M$ will never remove compatibility (or legacy if you like 8)) on old systems.....
They have not done this when NT come out will not do it for remakes like Win8. The truth is that if a user cannot run an old program on a new system maybe will switch to something completely different ::)
Today the open software have almost nothing less the commercial counterpart, so customers may move to Linux, or if the like 'fashion' side (a lot of money just for look) to MAC.......
-
@Ralf, sad that the PE patcher is a 16-bit application and doesn't support 64-bit executables ;)
What could possibly be the purpose for that be? ::)
- Being able to run on Windows versions higher than XP, since 16-bit support is removed in those releases.
- Being able to change the sub-system version of 64-bit executables, if the linker raises the default version without offering a way to decrease it.
-
M$ will never remove compatibility (or legacy if you like 8)) on old systems.....
The PE patcher mentioned here can't be run on Win7, since it is 16-bit, so M$ has already broken legacy support.
You are not able to use any 16-bit executable on Win7, so any of your ancient applications will get moved into the trash can :'(
-
Yes,
they tryied to make the trick, then how can we say ... a step forward and two steps back ? ;D
http://windowsteamblog.com/windows/archive/b/windows7/archive/2010/03/18/windows-xp-mode-now-accessible-to-more-pcs.aspxThey would like, but they added more bloat.....
Many want to "drive" customers to new ways, but customers with no money due to chrisis, and with a lot of machines, don't agree.....
That is not valid only for PC's......
-
M$ will never remove compatibility (or legacy if you like 8)) on old systems.....
The PE patcher mentioned here can't be run on Win7, since it is 16-bit, so M$ has already broken legacy support.
You are not able to use any 16-bit executable on Win7, so any of your ancient applications will get moved into the trash can :'(
Not to put too fine a point on this... but...
32 bit distros of any windows version will run 16 bit code.
64 bit distros of any windows version will not run 16 bit code.
It has to do with the WOW emulator...
-
M$ will never remove compatibility (or legacy if you like 8)) on old systems.....
Sure they will...
win2000 dropped support for 8 bit code...
64 bit OS versions drop support for 16 bit code...
There have been several video subsystems (cga, ega, etc.) that are dropped.
The old interrupt driven COM ports are no longer supported.
Older sound cards with MIDI hardware are no longer supported.
The original ISA buss is no longer supported.
And there's more.
-
@Ralf, sad that the PE patcher is a 16-bit application and doesn't support 64-bit executables ;)
What could possibly be the purpose for that be? ::)
- Being able to run on Windows versions higher than XP, since 16-bit support is removed in those releases.
- Being able to change the sub-system version of 64-bit executables, if the linker raises the default version without offering a way to decrease it.
64bit exists only since Windows XP, so there is very little use for this tool IMHO...
Ralf
-
M$ will never remove compatibility (or legacy if you like 8)) on old systems.....
The PE patcher mentioned here can't be run on Win7, since it is 16-bit, so M$ has already broken legacy support.
You are not able to use any 16-bit executable on Win7, so any of your ancient applications will get moved into the trash can :'(
That particular program that I mentioned was the result of a 10 secs (or less) Google search and did the trick running on Windows 2000 (the OS that was giving czerny problems).
And as this is a programming related forum, it shouldn't be too hard to create a more purposely (in regards to patching the OS version numbers) as a simple programming exercise 8), on whatever OS tickles your fancy ;)...
Ralf
-
What I have done for version 7.0 is to move all build steps into *.ppj files - previously, for historical reasons, it was a mix of makefile's and *.ppj files.
The final version of all tools are (or should be) compiled with pocc, linked with polink etc. - but I also need intermediate versions since I can't create files "out of thin air"; the intermediate versions are built using Microsoft tools (not the previous version of Pelles C, for various reasons). For example, I need crt.lib before I can link polib.exe, but I need my own library manager ("polib") to build crt.lib. Catch-22. There are many similar cases...
Right now I have the intermediate files msasm, mscc, mslib, mslink, msmc, mssign. With almost every sub-project depending on every other sub-project, it took a while to arrive at this (minimal) list since I want to use the final versions as soon as they are built (polink.exe rather than mslink.exe, etc.)
It looks like polib.exe is currently linked using Microsoft's link.exe, which looks like a bug ...
-
Puuh! That sounds promising!
the oldtimer :)