Edit and Continue

Long time ago, I have sinned. Yes, I used Visual Basic 6.0 to make programs. Even worst, I got paid to do so.

My work involved working with medical devices (oh, AxSYM, how I miss you…) there was one killer feature for me. Ability to set breakpoint, change some code and resume from that point was priceless. I would connect to device, when something in communication goes wrong, I would edit code in place, fix a bug and continue onto next packet. I could afford myself to be lazy (ok, there were timeouts to consider) and fix few bugs that occurred in single session. How did I liked it.

When .NET came I was missing that feature. I cannot say I was too sorry for old VB since new VB.NET was so much more powerful, but some things took a little more time and concentration to be done.

For Visual Studio 2005, there was a treat for me. They reintroduced that very same feature as “Edit and Continue”. It wasn’t as good as one in Visual Basic 6.0, even small changes would force you to restart, but smaller adjustments were possible. Life was good.

Recently, I switched to 64-bit system. I figured that since 64-bit systems were gathering momentum, so should I.

It was not as smooth transition as I hopped. There were driver problems, non-working 16-bit programs, some API calls that kept failing since I had int instead of IntPtr. All those things are nothing compared to not having “Edit and Continue” again.

Not only that I lost it, there is stupid dialog that reminds me of it every time. You can turn whole feature off in order to prevent that annoying dialog, but then you cannot play with it even on 32-bit applications (yes, feature still works if you compile for x86).

I do not use it often anymore. It is just to annoying to switch between Any CPU and x86 platforms. However, when I have some weird problem at hand, and I see that lot of debugging is involved, switching temporary into 32-bit world is small price to pay.

When to Go X64

Sometimes it is hard to tell wether to work in 32-bit or 64-bit world. Here are some hints.

Hyper-V

This one is easiest. To use Hyper-V you must use x64 windows. End of story.

Windows XP

This was first consumer choice of 64-bit operating system and as such it had some problems. You can argue that most (if not all) problems were caused by lousy drivers, but fact remains that there were problems. Later drivers fixed this situation, but I would not recommend this version to anyone.

Vista / Server 2008

Here situation depends mostly on memory. It is easy if you have more than 4 GB of memory (e.g. 6 GB). You must use 64-bit windows to use all that memory. There is choice of using 32-bit Windows Server with PAE which then enables usage of more memory, but I would not recommend it since performance cost for that memory is too high.

Here I must say that 64-bit drivers are really stable now. Device manufacturers really learned their lesson with Windows XP x64 and now everything works as it should. There can be some issues with finding proper and signed driver (driver signing is requirement) for older devices, but for newly bought devices everything just works.

When you have just 4 GB of memory there is slight dilemma. 32-bit windows will see less than 3.5 GB (even with /3GB switch). Rest of memory will be simply unavailable. However, in 64-bit world pointers are bigger (eight bytes instead of four) so all that additional memory is just used for larger pointers. Useful memory (used for data) is roughly the same.

Here I would go with 64-bit Windows (if all drivers are available). You will have no advantages now but if you add more memory to your computer, there is no need to reinstall anything. Also, from developer perspective, you can track those pointer bugs (e.g. .NET interop calls) more easily since most of them are there because someone decided to put pointer (64-bit value) in integer (which is 32-bit value even on 64-bit system).

When there is less than 4 GB, memory is just wasted if you go 64-bit.

Small Basic

My first programming steps were done in GW-BASIC but quite soon I switched to QBASIC. Those languages were simple to learn and they gave instant results. Yes, you couldn’t do anything really big (or useful) in them, but they had a power to make your eyes glow when some simple idea became a real program.

When I started programming for money I switched to C/C++ for a while, until I discovered Visual Basic. Although it had lack of C/C++ power and control, no one can deny development speed (faster I create something, more money I earn).

It is hard to recommend any high-level language for learning programming to kids. You just need to learn too much of boring stuff in order to do anything that looks even remotely fun.

But now, there is Small Basic. That language doesn’t even try to be serious. Whole point is just to have fun - not productivity. It’s interface is simple and nice. Intelli-sense is not only useful and descriptive (it is more detailed than some help files I saw) but it really gives you that “someone gave this some thought” feeling.

It does borrow some nice ideas from other “kid languages” (turtle from LOGO comes to mind) but there are some ideas that will take a kid instantaneously. For example, there is special class for accessing Desktop (e.g. change wallpaper) and accessing photos on Flickr. If that doesn’t enchant your kid, I don’t know what will.

If you, as a big kid with big toys, feel left out in this story - you are wrong. You can extend this gem with your code written in .NET thus giving your kid access to “only sky is a limit” world of ideas. You and your kid can do each its part of code and have fun. I find this precious.

Work Half-done

I love VHD mounting feature in Windows 7. It makes playing with virtual machines much easier. And let us not forget installing Windows 7 inside it.

You just go onto More Actions and select Create VHD (although this was hardest part for me since I am adjusted to right-click mentality). After that there comes a nice dialog.

This dialog gives everything in simple terms. If you decide to create fixed disk (as you should), Disk Manager just blocks. No progress bar, no message - plain and simple nothing. As you can imagine creating 20 GB can take a while. Only signal that something is happening is light of your disk.

I find this a little disappointing. Another great feature tarnished by half-done user interface. :(

[2008-05-08: This is fixed in release candidate.]

Open Packaging Convention

For it’s XML based file formats (XML Paper Specification and Office Open XML) Microsoft used zip file as storage (not a new thing - lot of manufacturers did use it before). If one is using .NET Framework, support already comes built-in (i think from version 3.0 but I didn’t bother to check - if you have 3.5, you are on safe side).

Since every package file can consist of multiple parts (look on it as files inside of package) it seemed just great for one project of mine.

ZipPackage

Class that handles that all is ZipPackage. It uses little bit newer specification of zip format so support for >4GB files is not an issue (try to do that with GZipStream class). Although underlying format is zip, it is rare to see zip extension since almost every application defines it’s own. That makes linking files and program a lot easier.

But there is (in my opinion of course) huge stupidity in way that writing streams is handled. Every stream first goes to Isolated Storage folder which resides on system drive. Why is that problem?

Imagine scenario where your system drive is C: and you want to create file on drive D: (which may as well be over network). First everything is created on drive C: and then copied to drive D:. That means that whatever amount of data you write, this class writes almost twice as much on disk - once uncompressed data goes on C: drive and afterwards gets compressed on drive D:.

That also means that not only you need to watch amount of disk space on your final destination but also your system drive needs to have enough space to hold total uncompressed content.

Even worse, if program crashes during making of package, you will get orphaned file in isolated storage. That may not be an issue at that moment but after a while system may complain about not having enough space on system drive. Deleting orphaned files could also prove to be difficult since it is very hard to distinguish which file belongs to which program (they have some random names).

Weird defaults

There is also issue that when you first create a part, it’s compression option is set to not compressed. That did surprised me since one of advantages of zip packaging is small size. Since every disk access slows things down, having file compressed is advantage.

Since every part is can have separate compression option, I tend to set them to Normal for most of it. Only if I know that something is very random (encrypted or sound), I set it to no compression. Speed is little bit slower when reading compressed data but I am still to find computer so slow that I have issue with uncompressing data.

To use it or not

I do hope that next version of framework will optimize some things (e.g. just get rid of temporary files). However, I will use it nevertheless since it does make transfer of related files a lot easier. Just be careful that there is enough space on system drive and everything should be fine.

If you want to check it, there is simple sample code available.