|George W[ar] Bush|
Date: 5/11/2004||Oh, what a shame, George is baaaack!
So now we can expect more:
The problem with this is that if any country unilaterally invades enough other countries then it's not going to end nicely. For instance take WW2, 2 countries start invading all their neighbours. 1 gets into a protracted land battle that ended with it's entire civil and industrial base destroyed, the other got nuked.
Gee I wonder which option the enemies of the US will choose?
Basically the US is asking to be nuked. As their administration gets more and more out of control the "terrorists" are eventually going to _have_ to nuke the states to put them back in their place (i.e. a country in Northern America, not the world's government and police).
I think it'll be a shame that 20 million people will have to die just to get the message through to the US gov. that what they are doing is not OK with the rest of the world. A real shame...
(Btw while we're at it, anyone who thinks that 9/11 was unprovoked has got their head firmly in the sand)
|(3) Comments | Add Comment|
Date: 1/11/2004||Because Scribe is moving towards a stable build, I'm going to start include .exe installer versions again... for the mainstream users... yeah.
Anyway, I'm looking at the section for uninstalling Scribe and I'm planning on having it remove all the executable code, program resources, help files... but leaving the folders.mail2 file that stored all the email and contants the user accumulated over the time they used Scribe. The other option of course would be to blow away the entire directory, mail, contacts and all. This however could land me in hot water... on the flip side... some people will complain either way. But I'm erring on the "safe" (e.g. leave the mail) rather than "sorry" side right now.
So, dear reader, what would you expect the uninstaller for an email app to do?
|(7) Comments | Add Comment|
Date: 25/10/2004||It would seem to me that after you got kicked out of one home you would be wary of making the same mistake twice. But it appears that the local miner birds aren't that smart. They have, over the last few days, tried to colonise the automatic roller door on the garage of our house. They did this last year at the other end, and I had to claw all the nest material out and board it up.
So this year they had a cunning plan. The OTHER END of the roller door! Which is mostly obsured by the motor that drives the door up and down. But it seems no hole is too small, and no obsticle too difficult (I stuffed the holes with plastic bags, which they removed). And now that end is filled with twigs and leaves and other litter. So now I've cleaned that out, scraping my arm on the gears and metal edges. And boarded that end up as well.
But the add insult to injury the door mechanism is now faulty, when the door reaches the bottom it gets confused and heads back up to the top unless someone manually turns it off.
|(2) Comments | Add Comment|
Date: 21/10/2004||Well after about a year of putting up with very quiet and distorted output from one of my Linux machines sound card I finally had "it" out with my Linux install and beat it into submission. If there is was any doubt that Linux is not ready for the desktop, then you need to try setting up audio.
I basically had to install a recent version of alsa, a somewhat painful process involving far too much terminal time and linux-fu for my liking. I used this recipe for my Intel i810 card.
I've now got crystal clear audio at full volume, but man... what a screwed up place Linux is to live. With Windows you just blow it away every so often (me: 1yr) and start over with a clean install. With Linux it's better to pick a kernel/distro to use for the rest of your life and then slowly get everything working. And you can never change or upgrade because the pain of getting everything working again is like having to give birth.
|(3) Comments | Add Comment|
|Microsoft Visual C++ 7|
Date: 18/10/2004||Microsoft's Visual C++ 6 is a rare treasure in the software world. It's fast, flexible, easy to use and has hardly any faults whatsoever. It's in fact one of my fravorite applications, and I spend a lot of time using it so I should know. So even when it does something annoying I'm very forgiving due to it's good behaviour on the whole.
Now recently I had the misfortunate of having to actually use Visual C++ 7 (VC7) in earnest for the first time. And man I was shocked at how far such a almost perfect IDE/compiler had fallen in just one major version release. VC7 manages to disappoint at lots of levels, and I can't see myself ever moving to it. Maybe I'll just skip 7 and wait for 8 (or 9 or whenever they get it right again).
First up I imported my VC6 project and built it... well tried to build it. You see they changed all the hotkeys for everything. Ok ok you can go and select "VC6 Hotkeys" in the settings somewhere to map them all back again but why change it? Why WHY WHY! It worked fine before and change for change's sake is plain dumb.
Ok, take a deep breath Matt. It's just key bindings. Next I try and link an application with a DLL generated in VC6. Doesn't work. Or maybe you need to know some "voodoo" to get it to work. Oh well time to upgrade all the projects to VC7.
Then it starts bitching about unresolved externals, because I exported some template class in the DLL. Ok ok fine.. don't export the class and it works. But why did that work in VC6 then? Why WHY!
Now it seems if you use "Multithreaded DLL" you also need a 337kb MSVCR70.dll in your applications distro, blowing out the download size. Grrr.
Ok so I need to change all 23 vcproj files to "Multithreaded DLL" instead of "Multithreaded". This is easy I say to myself (Que peanut gallery: snicker snicker). I'll just select all of the projects at once and edit the setting all in one fell swoop like in VC6. Um, No. You have to open every proj settings separately and change the setting. Argh, stupid stupid stupid.
And now that I'm in the swing of it, lets try and clean one project... opps the clean just cleaned ALL the projects. Thats not annoying at ALL!
Ok rebuild them all. Hmmm, compile is nice and quick. But the "make" functionality that checks for changes and rebuilds the required parts of the projects is sooooo slllllooooowwwwww II'mmmmmm faaaaalllllllliiiinnnnngggg aaassssslleeeeeppp. Bloody hell, how does anyone get anything done!
Oh well what can you do? It's like a Microsoft product.. and they are world champions at ignoring customers. Anyway I was building and fixing the code... just doing my normal coder type stuff and I was wondering whether I could get to the definition of a symbol easily. Oh look a "Go To Definition" menu item. Excellent. The symbol "blah" is not defined. Hell it is! It compilies doesn't it! Stupid. VC7.
And finally I did get the impression that everything is just a little sluggish in VC7. The menus, the dialogs, the time it takes for windows to open, the startup time, the time to paint the windows. It's all just slower than VC6, like everything has been spray painted with a "slow gun". It also has this charming trait of randomly locking up for a few seconds every now and then FOR NO REASON AT ALL. Which of course I LOVE. The end result feels unfinished and cheap.
All I can say is "Dot Net. You Bet... ter not make me use it".
|(2) Comments | Add Comment|
|MS Visual C++ Madness|
Date: 14/10/2004||For those who write code in the Microsoft Visual C++ environment here is a little pearl of wisdom for you. In the project options, you can build with several types of "Code Generation":
But there is more to it than that. In fact something which I found quite disturbing. (And I'm assuming that no one uses Single Threaded anymore).
There is a major difference between "Multithreaded" and "Multithreaded DLL" that is not so obvious, in a "Multithreaded" exe and associated DLL's the memory allocated by the DLL cannot be freed or realloc'ed by the exe and visa versa. With the "Multithreaded DLL" code gen you CAN free memory in the exe that was allocated in a DLL.
Now there are 2 camps here, the DLL crowd and the non-DLL crowd. Both have written swathes of code based around the assumption that the memory model has always been this way. I certainly had no idea the other camp even existed until today. But I met someone from that camp and had a good 'ol argument about it. In the end we both realised there is a whole other model out there that we just didn't know anything about. Lgi is firmly written in the DLL camp, and can't be used in just "Multithreaded" mode even if you wanted to.
I think the technical reason behind all this is that when you link to msvcrt.dll (i.e. "Multithreaded DLL") you get 1 clib (e.g. malloc/free) and 1 heap. If you don't, each DLL and exe has it's own clib and it's OWN heap. And the malloc and free calls don't work with memory from another heap.
And I've been coding for how long without realising all this? ;)
|(1) Comment | Add Comment|