Powerbook runs XP
It's done. The contest has been won.
Windows XP is installable on a MacBook Pro and it even boots from there after the installation.
This solves a big problem I'm having: In the office, I'm using a 30" cinema display connected to a Windows XP box which I had to custom-build because no out-of-the box systems have graphics cards with dual-link DVI ports which is needed for all resolutions bigger than 1920x1080 (technically, the limit is even 1600x1200, but 1920 still works somehow).
Now, custom-built boxes are nice, but they have two flaws: The first is the noise. Even though I got it to run very quiet despite the kick-ass graphics card I had to put in, it's louder than your average laptop (it was even louder before I unplugged the chipset fan. As it's working stable since more than a year now, I guess it doesn't matter). The second problem is the problem of data redundancy:
If you prefer and have the ability, like I do, to both work at home and in the office, you are dependant of having current data at both places. Version control systems help a lot here, but they don't solve all the problems (unfinished revisions which I don't like to commit and binary files). In the end, the only way to have your data where you need it is to maintain it only at one place at a time.
This is the main advantage I'm seeing in laptops (beside the quietness).
Looking at the current laptop pc market, it's even worse in respect of dual-link DVI outputs: Usually, you don't even get single-link DVI. And custom-building one is no option unfortunately. There are some barebones, but what comes out of such an operation is a loud, badly manufactured "thing" with short battery life.
So, hardware-wise, powerbooks were always perfect because all of them have my direly needed dual-link DVI port.
The problem was the software. I'm dependant on Delphi for my daily work. Even if days can pass without me actually using it, it still happens that I need it. And when I do, it must be quick.
The other thing is multimedia. No matter what you are now going to tell me: Nothing on the Mac matches the perfect architecture of DirectShow which allows media players and codecs to be developped independently. Core Media Player with the right codec pack is unbeatable in performance, usability (at least for me) and versatility. Sorry Quicktime (only quicktime and maybe DivX). Sorry MPlayer (always uses 100% CPU, awkward GUI). You just don't beat that.
Also multimedia related is my passion for speedruns and superplay movies in particular. For the latter ones, you need the emulator and the original ROM and especially the emulators (some of which are patched for the movies to work) don't run on the Mac Platform and if they do, they only do with some limitations (like pausing the emulation stopping the playback of the movie in Snes9x).
If I want a single computer to work both at home and in the office, it must do both: Provide an environement to work with and an environement to play with.
OS X allows me to do some developement (TextMate comes to mind), but not all. It allows me to do some multimedia (XVid works sometimes), but not all. Thus, OS X is currently not a solution for me. At least not the single one (I'd love to work in TextMate for PHP and Ruby, eclipse for Java, but I can't do Delphi or Windows CE).
So what I need is Windows (where the software does everything I need) on a Macintosh Laptop (where the hardware does everything I need).
Up until today, this was not possible.
Now it is. This wonderous hack (which is not completely disclosed yet, but I have a very good idea how it works) solves my problem in allowing me to combine the optimal software (for me. I know lots of people who can be perfectly happy with OS X) with the optimal hardware (for me).
Needless to say that I've ordered a MacBook Pro at our hardware distributor. They even had 13 on stock, so I'll be getting mine tomorrow.
I hope the hack gets disclosed shortly, so I can do that nice dual-boot configuration :-)
Or maybe Virtual PC just works good enough for delphi and the speedruns...
Update: A howto with needed tools is now ready to be donwnloadedRead on →
Sure. Just dump your trash right here!
Boy was I pissed when I read my mail today:
Dear Spammer. What do you think to get out of this? All links your post will be masked, so no page rank for you. And I will almost certainly not overlook something like this (400 comments in one night), so no chance in it persisting either.
I'm sick of cleaning up after you guys. Dump your trash somewhere else. /dev/null sounds like a nice alternative.
Oh, and MT: Why did your Spam filter not catch this?Read on →
PHP Stream Filters
You know what I want? I want to append one of those nice and shiny PHP stream filters to the output stream.
I have this nice windows-application that recives a lot of XML-data that can be compressed with a very high compression factor. And as the windows application is for people with very limited bandwith, this seems to be the perfect thing to do.
You know, I CAN compress all my output already. By doing something like this:
<?php ob_start(); echo "stuff"; $c = ob_get_clean(); echo bzcompress($c); ?>
The problem with this approach is that the data is only sent to the client once it's assembled completely. bzip2 on the other hand is a stream compressor that is very well able to compress a stream of data and send it out as soon as a chunk is ready.
The windows client on the reciving end is certainly capable of doing that. As soon as bytes come in, it decompresses it chunk-wise and feeds it to a Expat based parser which will handle the extracted data. Now I want this to happen on the sending side aswell.
The following code does work sometimes:
<?php $fh = fopen('php://stdout', 'w'); stream_filter_append($fh, 'bzip2.compress', STREAM_FILTER_WRITE, $param); fwrite($fh, "Stuff"); fclose($fh); ?>
But sometimes it doesn't and produces a incomplete bzip2-stream.
I have a certain idea of why this is happening (no sending out of data to the filter on shutdown), but I can't prevent it. Sometimes the data is not put out which makes this method unusable.
I'm afraid to report this to bugs.php.net as I'm sure it's something PHP was not designed for and it'll get marked as BOGUS faster than I can spell 'gnegg'.
So this means that the windows-client just has to wait for the data being extracted, converted to xml and compressed.
(thinking of it, there may be this option of outputting data to a temp-file (to which handle a filter is assigned to) and the read it out to the browser immediately afterwards. But come on, this can't be the solution, can it?)
Update: I've since tracked the problem to a bug in PHP itself for which I found a fix. My assumption of writing to a temporary file could help was wrong as PHP itself does not check the return value of a bzlib function correctly and never writes out a half-full buffer on stream close. Neither to the output stream nor to a file.Read on →
There are quite many solutions available to you if you want to create printed (or PDFed) reports from your delphi application, but surprisingly, one one is really convincing.
The so called professional solutions like Crystal Reports or List&Label are very expensive, require a large runtime to be deployed and may even require you as the developer to pay royalties per delivered client
So for my particular problem, the only solution was to use a VCL based engine that can be compiled into the exe and does not need any additional components to be deployed.
Years ago, I was told to use ReportBuilder and maybe people were even right there: Quick Reports (as in included into delphi back then) had and still has a very bad reputation, and RB was the only other VCL based product available
RB has some problems though. Lacking Delphi 2006 support, limited report templates, field formating on the database access layer and last but not least: A nasty bug preventing barcodes from being correctly rendered to PDF-Files.
Then, I had a look at Fast Report and I tell you: That piece of software is perfect!
Granted, switching will come with a bit of work, though the paradigms of both engines kinda match. But once you've done the stupid rebuilding of the old templates, you'll notice how wonderful Fast Report actually is. And you will notice immediately as it's very, very intuitive to use - compared to RB. Things that required custom programming or even a little hacking here and ther in RB just work in FR. And they even work without forcing you to read through lots of documentation in advance
And everything - just everything is in the report template. Number formats, even small scripts for changing the report in subtle ways while it's being printed. Just perfect for what I was doing.
So, if you are looking for a nice, powerful really easy to use reporting enginet that can be fully compiled into your EXE, you should really go with FR. It even costs less than RB.Read on →