Seems the new CFF Explorer will be compiled with GCC. More than one reason for that. Visual Studio 2008 doesn’t support anymore Windows 98 and NT4 without giving an explanation. The incompatibility is due to a major operating system version inside the Optional Header of the PE and to the fact that the C runtime library makes some unsupported calls. I could of course patch the whole thing and manage to make it run on those operating systems, but why should I? This is not my job. It should be Microsoft’s job to offer an alternative compiling method which provides backward compatibility. What angers me is that Microsoft not only doesn’t care about backward compatibility, they don’t even bother explaining why they had to remove the support for those operating system. The GCC (Mingw) runtime makes it possible to even compile Qt programs for Windows 98 (which is possible with VC++ 2005 too, but it forces me to use an older compiler). And, as I might not be interested so much in Windows 98, I really am interested in providing compatibility with NT4. Or, at least, if it doesn’t offer backward compatibility I want it to be for a better reason than the C runtime. I’m sick and tired of these decisions Microsoft imposes. Just like the XP support which soon will end (actually I haven’t understood if it ends this month or in April 2009). As I understood for OEMs it ends this month. Anyway, I managed to compile the CFF’s kernel with GCC and also fixed lots of errors signalled by that compiler. Another good reason to use GCC is that it’s cross platform, meaning that a port would be much easier. The only drawback of Mingw is that it has a very small (and not up-to-date) Windows SDK, but I’m not interested in that, especially for the CFF Explorer which should become 100% platform independent. At the moment I reached 97% platform independency. My only complaint is directed to the ansi C library. My goodness, you can’t do anything with the IO functions it provides. I’m grateful that they were so kind to provide 64bit support for files: fseek64, ftello64 etc. But there are lots of things missing. For instance, I am unable to truncate a file… In a normal world that would be: FILE *f = fopen(..); ftruncate(f, len);. No, that’s not possible at all in ansi C. That really bothers me, because it forces me to write platform dependent code for my basic programming interface.
EDIT: Seems the new QFile of Qt 4.4 implements the resize method for files and that would do just fine.
So why exactly should Microsoft support an antique operating platform? The Win 9x series is end of life for some time, using it makes no sense and you are exposing yourself and others to danger if you connect such a machine to the Intertubes (by adding one more zombie machine).
Microsoft made the right decision here and if you are still running Win 9x, you should really, really look for alternatives.
I have been running Vista x64 for quite some time. If you look, I wrote one of the first articles about Vista & x64. I’m not interested in Windows 98, much more in NT4. And EVEN IF, I expect Microsoft:
a) to give a full explanation for not supporting NT4
b) provide an alternate compiling with an older C runtime
From your comment I clearly understand that you didn’t even bother reading the post, so why commenting at all?
Moreover, the CFF Explorer is an internals tool. I wouldn’t recommend to use an old operating system, but the application itself should be able to run with a minimum of requisites (especially if it is possible).
Actually, it seems there are functions ftruncate() and truncate(), at least they are present in both glibc and cygwin’s newlib. Also, man ftruncate reveals some history:
The truncate() and ftruncate() function calls appeared in 4.2BSD.
It’s just Microsoft not really supporting what all the other world uses. Be it fork() or a totally borked argument concatenation in exec*() and spawn*(). :-/ So I’m not surprised something so vital is missing, and mingw supports only those things that are exported from msvcrt.dll.
Mmmh, if you go this way, maybe it
is also a short step to port it to different systems ?
A UI version and a none UI version ?
Sometimes (but maybe not for much peoples) it is important to have a tool which works in and also for different systems.
Ouch, wrong man page. truncate and ftruncate are posix.
http://www.opengroup.org/onlinepubs/009695399/functions/ftruncate.html
snaury: well it’s not totally ANSI, I guess, (the msvcr doesn’t support it) and not only that, it doesn’t work with fopen. If you look at the function it doesn’t accept a FILE * argument. That’s why I specified this factor in the post. I already saw that function. But thanks anyway.
edgar: it is a very short step to bring it to other system, even with GUI since the Qt framework works on every possible system (win, mac, linux, bsd etc). Not only that. I made the CFF endian aware. It could work on a power pc as well.
The ultimate goal would make the CFF run on many systems and adding support for many more formats other than PE.
FWIW, if you use an older Edit Bin as part (e.g. not part of VS2008), and tie that to a post-build event, you can get it to work for NT. Can’t vouch for Windows 98.
Well thanks torial, I guess sooner or later I’ll have to go back at VC++, since I already noticed that compiling python on windows with mingw is a mess. So, most certainly I’ll go back to that and will look into you just said. This post should be taken more as a rant than something serious, but it’s true that in the last months I managed to work with gcc only.
use gcc it could do anything if you
know how to use it all of linux is
compiled with gcc so i think that cff explorer could be compiled with
gcc