Parallels & Custom Screen Resolutions

Custom screen resolutions ( CSRs ) in Parallels Desktop for Mac are something that I haven’t really played around with too much. When editing the preferences for a individual virtual machine, you have the option of setting up custom screen resolutions:



Picture 1-4

I couldn’t really come up with a reason which I would need one. When running Parallels on my MacBook Pro, the default 1280×800 worked fine. When using my 17-inch ViewSonic as a second screen, the stock 1280×960 resolution worked great.

Today, I am running on my MacBook Pro, which runs at a native 1440×900 resolution. It would be nice if Parallels would take advantage of more real estate than the 1280×800, but I didn’t want to run it in full screen mode, since I still use a lot of other Mac OS X apps….

Here’s where CSRs come into play. I setup a new CSR for 1440×900, my LCD’s max resolution. When you boot up your VM, the new resolution is now available from the Display Properties->Settings tab:

Picture 2

While this seems like a good idea initially, i quickly realized that I couldn’t have my vm the exact same size as my MacBook Pro LCD because I wouldn’t be able to see anything else. So i adjusted the CSR to be small enough to fit onto the screen, but big enough so that I get some extra real estate for my VM.

The sweet spot CSR? 1400×820.

This allows me to still see my mac menu bar, the right hand bar of parallels as well as the bottom status bar of parallels. I should also note that I use QuickSilver exclusively, so I have no use for the Mac Dock. I have hidden it, so the above CSR will have to be narrowed if you still use the dock ( I weep for you if that’s the case )

Sweet.

ReSharper makes a stunning comeback

EDITED: Looks like JetBrains is working hard, because there’s already a new 2.5 EAP build out, build 301. The original build described below was their 300 build. Excellent….

My turbulent relationship with the excellent .NET add-in ReSharper from the folks over at JetBrains is well known to readers of this blog.

Well, they’ve gone and done their best to entice me back: they’ve released initial VB.NET support. Yes, that’s right. The proverbial runt of the .NET language litter is now a first class citizen in ReSharper ( how much sense does the name ‘ReSharper’ mean now? ).

With the release of their 2.5 EAP, JetBrains has included initial support for Visual Basic, which they’ve said is read only. However, either they don’t want to officially acknowledge write-support in VB.net, or a sneaky developer has gone ahead and fleeced the marketing folks, because the I am experiencing write support. This includes refactorings:

Picture 4

Picture 3

Oh, and did I mention that it’s MUCH FASTER than previous ReSharper 2.0 builds. Looks like my saucy mistress has lured me back….

Read their blog post here or just go ahead and download the new EAP.

Keith Olberman takes it to the president

As readers of this blog may or may not know, I have a connection to the current military occupation overseas. My best friend of almost 15 years is currently stationed somewhere in Iraq ( he can’t tell me where ). This is his second tour in Iraq. During his first, he was stationed right in Baghdad Airport. He’s an MP, and was recently promoted to the rank of captain at the young age of 25. I try and send him whatever I can. We can only hope he makes it home safely in March.

Unfortunately, I have already lost a cousin overseas. My 21 year old cousin was a sniper, perched in a building that was destroyed one morning. To him, the military gave his life purpose. A life that would have led to jail or worse. My family, while saddened by his death, took solace in this. He was doing something he believed in.

I don’t really post about politics because they’re one of the hot button topics amongst people. However, as the death toll, both us military and iraqi civilians, rises in the recent months, more and more anti-war momentum has been building. Today, I found these clips of Keith Olberman calling out the President in a way that I thought was lost, or at least, not to be seen on network tv.

Watch these videos. There are two parts.

IIS HTTP Compression and Streaming PDF's: Don't do it.

It started simple enough. We were generating PDF’s to stream down to the a browser. Everything worked fine in development. We moved the release to our staging environment, which mirrors our production environment.

BOOM

No PDF’s. Just a blank Acrobat window.

Ok, first things first: what’s different? Ah HA, staging has SSL enabled. Ok, quick run through to enable SSL on our development environment should let us know what the problem was. Except that wasn’t it. We enabled SSL and everything still worked. There’s even a well known bug in IE with regards to Office documents & SSL. But our site wasn’t working in FireFox either.

We were stumped. Then someone says “Let’s look at the Response Headers”. Brilliant. What do we find? GZIP. “Oh, yeah, BTW, we have HTTP compression enabled in prod / staging” someone says. Damn. Corruption and Compression both start the same way, after all. This makes sense because we were still getting PDF’s. They were just corrupted. We figured that the browser was trying to pass the PDF to Acrobat BEFORE decompressing it, which would make Acrobat bomb out.

Quick trip to google to see how to enable HTTP Compression on our development environments revels that, well, you can’t. HTTP Compression isn’t available on Windows XP. Ok, so what now? Google tells us that you can turn compression off for certain files and directories, but we don’t want to take a drastic step like that just yet. After all, these PDF’s can be big and compression would help with bandwidth issues. Plus it meant digging in the IIS metabase, and we could figure out a better way right? RIGHT?

Here’s a small list of things we did try, all to no avail:

1. Change MIME type from application/pdf to application/octet-stream.

2. Explicitly set the content parameters on the response headers ( Length, etc.. )

3. Move from using Response.WriteFile to writing the explicit byte array to the Response output stream

4. Changing the casing of the variables we were setting in the response headers ( Content-Type vs. content-type )

5. Alter the Content-Disposition header

6. Flush the Response before sending the file only

7. Flush the Response after sending the file.

8. Flush the Response before and after sending the file.

9. Alter how we were generating PDF’s ( using different PDF generation libraries )

10. etc…

As you can see from the list above, we were desperate. We were just about to bring out the live chickens to sacrifice, when I tried to disable HTTP 1.1 in Internet Explorer, which would disable HTTP Compression support.

Bingo. There’s a day i’d like back. So, it seems, we have to disable compression on pages serving up PDF content. Of course, this is what we expected and knew we could do if we wanted to, but we were smart guys right? We could figure it out right? The moral of the story? Sometimes the simplest answer is really the right answer.

However, we didn’t want to have to go into the metabase every time we added a page that shouldn’t have compression turned on, so we created a single directory that will hold our non-compressed pages. Then, we simply turned off compression for that directory. This took no more than 10 minutes, and most of that was creating the directory and moving the pages.