Kind of an old idea for a program that I only just remembered: a consensus-based climate control system for big offices. It'd be a client server app. The client would be a little thing in your taskbar that let you specify whether you were too hot, too cold, or just right. The server would gather all these inputs and bump the temperature of the office up or down accordingly.
Reason for having these 3 discrete choices: if clients were allowed to set the temperature on a continuum & then this was averaged to determine office temp, the system could be easily abused, ie if I want it hotter I set it to 120 degrees.
Oh, the horrors (I mean joys! joys!) of Pocket PC programming, it was so long ago I'd almost forgotten. Currently I am writing a little dll in EVC that can perform custom installation tasks.
Aside. Back in my Siemens era I remember days and days of weeping and gnashing of teeth over the unicode/ansii thing, I wanted to use stl's strings rather than nasty CStrings or even nastier LPCTSRs, the goal being some degree of platform independence. But I couldn't ever figure out when to use std::wstrings and when to use std::strings. After two years of not thinking about the problem, though, it took me maybe an hour yesterday to realize I should just typedef a tstring to be wstring when _UNICODE is defined, and string otherwise. Voila.
Anyhoo that's not to say things still aren't nasty & I suddenly want to be a Pocket PC programmer again. No way. I am running into problems even in this little custom install module. In it I try to fire off \Windows\unload.exe to force an uninstall of an old unsupported version of our program. unload.exe complies, but not before inexplicably posting a WM_CLOSE message to my process, killing it on the spot. There are a number of google groups posts on this & no helpful replies, yet.
So I am looking at doing unload.exe's job myself. I was warned in this article that I shouldn't attempt this, because WinCE has a special way of managing files shared between different apps. (Read: dlls.)
Well that's a strong argument against do-it-yourself. But I couldn't help but wonder, what's WinCE doing to the registry and filesystem that I can't duplicate?
Answer: nothing. Using EVC's Remote Registry Editor I exported snapshots of the entire registry before install, after install, and after uninstall. Luckily .reg files are plaintext so I could diff them. Only regkeys beneath HKLM\Software\Apps changed.
Then, after porting md5.cpp over to WinCE, I did a recursive listing of the entire file system including md5 checksums for each file. I diffed these filesystem snapshots and found that, again, the only things that changed were the expected ones in the expected places.
So I am on the verge of writing my own unload.exe. It's pretty easy, you just grok the \Windows\MyApp.unload file and remove everything listed there in order. It also lists dlls which I suppose you should unregister, but I think I'm going to ignore \Windows\*.dll, and thus sidestep any of the sharing problems that article mentioned.
Oooo! I may have finally found the perl module I've been looking for all my life (well, ever since my life became data-centric apps): Tangram. It handles orthogonal object persistence and does an object-to-relational model mapping. It supports either MySQL or Sybase (which I think implies MSSQL).
Basically, in plain English, this means you can just forget about your database backend and concentrate on writing code that *actually does things.* Compare this to incessantly worrying about mapping database tables onto your objects and back onto tables again. Add session persistence via CGI::Session, xml serialization and deserialization via XML::Simple or XML::Dumper, hook in your favoriate xslt processor, and there you have it, nine tenths of your typical web app is already written, leaving you to implement the interesting stuff.
Gonna try it all out when I get the time (ha ha).
Crap. I need to use an ssh2 key to make sftp work and an ssh1 key to make wincvs work. There's nothing stopping you from setting up two keys but I'd really rather not force 50 developers to add another key.
This situation is especially irritating because both these problems are bugs. There's no reason why sftp can't tunnel over ssh1, as far as I can tell it just uses ssh2 by default & there's no way to instruct it not to. WinCVS for its part ignores the contents of the "additional ssh options" box which contains the all-important "-2" parameter.
Sigh. And after I just spent 5 hours setting up chrooted sftp access by compiling custom shells.
I really should start a separate category for whiny entries like this one.