2006-01-25
I updated my patch for OpenTTD to add a simplistic IRC client today, it now builds fine against r3426, assuming you can add a single c file to your build scripts (I've only got it for Visual Studio 2005 (for which there isn't a project file in svn yet), so no matter what build system/os you're using it will need updating).
I belive it's cross platform, although I'm yet to check that as yet.
The current one is written in a MUD-style, with all the channels going into one window. For low-traffic channels this is equally, if not more effective than having multiple windows (especially with the cunning context-logging, so you don't have to /msg the same channel/person more than once in a row).
Mutliple windows really isn't practical, as far as I know no pure-IRC clients do non-MDI multi-windowing. A tabstrip could work, it'd also be resonably effective in other areas of OpenTTD (load/scenario/create-game dialog is effectively the same thing anyway, it just has a few different views, etc.), definitely worth looking into at some point.
2006-01-23
I was trying today to think of an effective way to securely copy files to another, restricted machine.
The idea of this being that no matter what happens to the source machine, the backups will always still exist (unless something nasty happens to the remote machine, too).
The simple way to do this securely against interception and the source machine having a physical faliure of some kind is to use an ssh-key+scp to copy archives across from a cron job.
This, however, means you have an ssh key lying around on the source machine; it doesn't even protect the backups against accidental overwriting, let alone intentional.
Firewalling and lack of access on the target machine means that running a server would be challenging, I'm yet to think of a good, safe solution.
2006-01-15
Having previewed the new Annual from the Ministry of Sound, and christmas having passed, I thought it was time to go buy it.
Unfortunately, thanks to the Ministry of Sound's infinite wisdom, the box that looks like this contains completely different cds to the box that looks like this.
Can't spot the difference? Have a look at the track list, according to DreamUniverse against Amazon's attempt. Ah.
I was after the version DreamUniverse are selling, for it's version of Hi Tack - Say Say Say, but I'm not paying for a company I've never heard of to ship me a cd that they probably don't even have a reliable track list for.
Back to 'sampling' it is for me, congratulations, Ministry of Sound, you just lost yourself another sale.
2006-01-11
As mentioned in
this bugslayer post, GetWindowLongPtr and SetWindowLongPtr are defined incorrectly when doing 32-bit compiles, meaning that my code is destined to create warnings until a fix is released. #pragma warnings do not count as fixes, sorry.
The warning (or error, if you're trying to build with treat warnings as errors) you get is:
warning C4244: 'argument' : conversion from 'LONG_PTR' to 'LONG', possible loss of data
2006-01-07
I noticed the other day that the 'enqueuing' functionality had disappeared from Winamp, which was mildly irritating, as it's really quite useful. I searched the changelogs.. no mention, then I remembered it was part of a plugin, JTFE.
Quick download, install using the installer, reload Winamp and.. nothing. No enqueuing. No extended jump-to-file dialog. And, furthermore.. no mention of the plugin in the list of "installed plugins" (which really seems just to mean "plugins in the .\plugins folder").
I tried poking it a bit, system log, dependency walker to check it wasn't looking for anything and dying silently, etc.. no idea. Last ditch attempt, re-install Winamp, no luck.
This necessitated me re-installing the last.fm plugin, which, although it loaded, and was submitting plays, bombed out Winamp trying to enter the configuration dialog. Quick search of their (actually useful) forums quickly came up with this post, which suggested turning DEP off.
This fixed the last.fm plugin, but also, surprisingly, fixed the fact that JTFE wasn't loading. Assumably something's trapping the DEP error it's encountering on load.. didn't know applications could do that, doesn't sound terribly good for security...
2006-01-03
I noticed today that http://localhost:32214 had enqueued itself in Winamp.. I have no idea when or why it happened, due to not getting near the bottom of my playlist very often, but.. what is it? Random open ports on a pc isn't normally a good sign.
A bit of investigation suggests that it's the last.fm player, which is strange.
last.fm has radio links on their site, but they're all done using a custom protocol, for instance lastfm://user/Faux/loved, so it apparently isn't those.
Launching the player, then immediately hitting the "Play http://localhost:32214" button causes something slightly strange to happen.. you get what appears to be a "200 OK" from the address in Winamp, then nothing.
Winamp, not getting anything from the station, gets bored and goes on to the next track, no surprise there.
The surprise comes when you try and use the last.fm player after this.. it doesn't work. It repeatedly comes up with "There is not enough content left to play this station.". I wonder how secure and stable the minihttpd they're using is? If the port's externally accessible, and they're expecting you to run the player full time, this could be a bit of an issue?
Also, I wonder what's going on, and if the last.fm's protocol is flexible enough to write a mini-proxy based on their source allowing you to use Winamp to handle the lastfm:// links.
Either way, opening random ports on people's machines without explanation is bad, mmkay?
« Prev
-
Next »
RSS Feed
