I don't think we have a 'touch' program in windows... although it probably wouldn't take much to create one.
I just find the whole thing amusing. And a tad confusing.
This is why I prefer to focus on the file version meta-data instead of the date.
Some of the effects at the Olympics opening ceremonies were powered by Windows ... and of course Windows did what it does best, displaying large BSOD for the whole world to see.
"To poof them out of existance, while leaving their real estate just where we need it..."
muahaha, a collegue had troubles with a program not working in vista.
The developer said, that this could be caused by file xy being present.
neither explorer (with show all hidden checked) nor the dosbox showed the existence of the files.
unveiled this after several hours of error searching.
Here's how you can easily crash Microsoft's Visual C++ 2005 consistently, and easily.
1. Install the boost library.
2. Create a class with a member function that requires an argument.
3. Use boost::bind() in this fashion: boost::bind( &MyClass::myFn, my_class_instance_variable );
Your compiler will crash on the boost::bind line.
Why? Well, you're making a mistake. Here's how you'd correct it:
boost::bind( &MyClass::myFn, my_class_instance_variable, _1 );
Here's how you can easily crash Microsoft's Visual C++ 2005
consistently, and easily.
And easily. And consistently. It's easy. And consistent.
Damn, but I suck.
Heh. I never really got the hang of C++'s "pointer to member function" type. It seems hard to use, and the wrong solution the the problem. I'm guessing that boost::bind is actually some ungodly template mess, under the covers, in order to work around the issue. No idea what the _1 is, either.
I've been using Visual C++ Express 2008 to build some open-source projects. It seems like a pretty good environment, but sadly it insists on compiling .C files as C, even when "compile as C++" is checked. Took me a while to figure out that I had to rename the file to .cxx.
They've also stripped a number of essential features:
* The 64-bit compiler. You can still get the 64 bit compiler as part of Windows SDK, and integrating it with the IDE is possible, but is probably a hair-pulling experience.
* Easy integration with SDK's - I don't see any obvious support for this, but I haven't tried it.
* Version control integration
* .RC file editing
Also, damn, it's annoying that they now force you to distribute MSVCR90.DLL as a .NET style bundle. You can't just include it in your application directory the old-fashioned way. God forbid.
I generally compile statically to avoid having to include a DLL.
I really, *really* hate Microsoft's insistent need to bundle everything into the .NET CLR nonsense.
This said, there's some sneaky way you can put the dll in your local folder anyway if you want, but it's ugly. Has something to do with providing some kind of text file during your installation or somesuch (probably the manifest).
On the other hand, if you use MSI to distribute your application, you can simply use their merge modules to ensure the msvcr90.dll is installed where it needs to go.
If you don't want to deal with MFC or .rc files, you might consider (maybe) using Ultimate++ for your GUI needs.
I really, *really* hate Microsoft's insistent need to bundle
everything into the .NET CLR nonsense.
When has Microsoft *ever* refrained from forcing its latest technologies down everyone's throats whether they want it or not?
Latest example: if you want to watch the Olympics on your computer, you have to install Silverlight.
I generally compile statically to avoid having to include a DLL.
Well, try doing that with a Qt app. Technically, it might not be a good idea to statically link to the MSVC runtime while a Qt DLL also statically links to the same runtime. It's like you and your team and carrying unlicensed particle accelerators on your back, and aim them at a target, while crossing the ion streams. It would be bad.
You'd end up statically linking with Qt as well, which is just kind of bloated and slow during the linking process...
You can install the DLL in your app directory but according to MS licensing you must distribute the bundle directory in its entirety. So you end up with a subdirectory containing 3 DLL's and the manifest, when you might only need 1 or 2 of the 3.
Are you allocating and deallocating memory across the Qt DLL boundary? That is, for example, are you allocating memory within your app, and having Qt deallocate the memory you allocated?
If you are, yeah, you are opening yourself up to some interesting times.
Similiarly, if you're using similiar functions across the DLL boundary, you may get mixed results (e.g. string collation... I knew someone who had subtly different string collations across dll boundaries, leading to some amusingly confusing results).
But, normally, these kinds of things can be controlled.
And one of the ways you control this is by compiling the third party toolkit yourself, if you can. Then you know you're on the same page as the rest of your application.
Really, though, you're only trading one form of hell for another, I guess.
But, as respective hells go, I'll stick with the static-library hell over the dynamic library hell.
At least I can control the static-library hell. I can't control the dynamic library hell at all; some customer will install something that will absolutely fuck you up, and you won't even know why.
I actually tried and failed to build Qt statically. I already had a working DLL build, so I didn't bother trying to figure out the cause. There were some undefined symbols (in one of the Qt samples or utilities, if I remember correctly.)
Do DLL's have a different heap than the calling process? That sounds... phenomenally stupid.
I'd already known that you couldn't pass C/C++ runtime library data structures to a DLL that is linked with a different copy or different version of the runtime. For example, you can't pass a stdio FILE* to such, for obvious reasons. I wasn't aware that the problem extended to all memory allocations, even if there is only one copy of the runtime at play.
The problem is more subtle.
The functions for allocating and deallocating memory differ slightly from debug/release versions of the C runtime. Further, they differ between dynamic and static versions of the C runtime. It isn't beyond imagination that they can differ between versions of the damned runtime.
As a consequence, if you mix-and-match allocation/deallocation across the DLL boundary, you risk using a routine that doesn't know how to deallocate the memory you allocated, but thinks that it does know how.
If this sounds phenomenally stupid, well... it is.