polib: broken error message

[Stefan Pendl]

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

[czerny]

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

[Bitbeisser]

@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

[CommonTater]

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.

[frankie]

M$ will never remove compatibility (or legacy if you like    ) 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.......

[Stefan Pendl]

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

[Stefan Pendl]

M$ will never remove compatibility (or legacy if you like    ) 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

[frankie]

Yes,
they tryied to make the trick, then how can we say ... a step forward and two steps back ? 

Code: [Select]

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

[CommonTater]

M$ will never remove compatibility (or legacy if you like    ) 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...

[CommonTater]

M$ will never remove compatibility (or legacy if you like    ) 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.

[Bitbeisser]

@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

[Bitbeisser]

M$ will never remove compatibility (or legacy if you like    ) 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 , on whatever OS tickles your fancy  ...

Ralf

[Pelle]

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

[czerny]

Puuh! That sounds promising!

the oldtimer