There have also been a few minor bugfixes and some changes to the documentation. Nothing too earth shattering, really, but the command line support was really high on the list of requests.

You can download version 1.1.0.0 from its page or directly by clicking here.

Dynamite VSP and Dynamite SIM technology will help Autodesk automate the process of creating visualizations for projects made with AutoCAD Civil 3D software. Dynamite VSP offers simple and efficient ways to bring AutoCAD Civil 3D software data into Autodesk 3ds Max Design software.

“We believe that every design has a story to tell. This acquisition will greatly simplify the process of visualizing complex AutoCAD Civil 3D projects with 3ds Max Design,” explained Jay Bhatt, Autodesk senior vice president, Architecture, Engineering and Construction. “It will help civil engineers tell their story in the most compelling way possible – validating their designs in context and showcasing projects for public consultation and approval.”

“With Autodesk’s research and development investment capabilities, this acquisition is expected to benefit our existing users as our technology is taken to the next level,” said Bruce Harfield, director of 3AM Solutions. “We look forward to working with Autodesk to further integrate the technology into the company’s existing software and advance Autodesk’s visualization offerings for civil engineers.”

“This acquisition will help empower users to more rapidly produce high-quality visualizations of civil engineering projects – even those without detailed knowledge of 3ds Max Design,” added Bhatt.

Read the full press release at 3am-solutions.com and autodesk.com.

Unzip the DLL to a location of your choice and you can use netload and load the Civil.RBC.dll (or if you want the functions available, hook it up in the acad2010.lsp file like this…

(command "netload" "C:/Your/Path/Civil.RBC.dll")

The commands supported are:

• RebuildAllCorridors (to rebuild all corridors)
• RebuildOODCorridors (to rebuild all out of date corridors)

If you wish to hook these up as macros use the RebuildAllCorridorsMacro or RebuildOODCorridorsMacro.

Download Civil.RBC.zip (3571 bytes)

There are many crucial aspects to the new version 4, the biggest of which is no doubt the full support for 64-bit (the virtual display drivers installed by MaxiVista 4 are digitally signed) and WDDM graphics cards. One of the things that the previous version had to battle with were the restrictions in Vista and the requirement to use XPDM drivers instead of WDDM. Well, those days are over with version 4.

Of course, all this also applies to Windows 7, not just Vista. So I will be looking forward to running an upgraded layout using Windows 7 once I get to the point of being done with that. Expect to see a more in-depth description and review of MaxiVista v4 in the next weeks. In the meantime, don’t take my word for it, try out MaxiVista yourself.

However, if I wanted to centralize the storage for the systems in the network, whereby the systems themselves were smaller, less top-heavy computers, I would certainly be looking at something like StarWind Server or StarWind Enterprise Server (probably the latter because I like the replication features). Also, if I were to overhaul the way my virtual machines are managed and stored throughout my network, and if I wanted to create a single cluster of systems to run that, StarWind would certainly get an even closer look.

So what is StarWind Server, you might ask. If you’ve familiarized yourself with the concept of a SAN, the short version of the story is that StarWind Server is a software product that turns a Windows 2003 or Windows 2008 server into a fully capable iSCSI SAN system.

Read the rest of this story over at Sallie’s blog.

You will need:

• A Windows 7 or Windows 2008 Server installation DVD
• The WIM2VHD script
• The Windows Automated Installation Kit for Windows 7 (WAIK)

Preparation:

Extract or copy the installation DVD somewhere (e.g. S:\W7INS).

Put imagex.exe and bcdboot.exe (from the WAIK) and the WIM2VHD.WSF in the same location (e.g. S:\AIK). Also put bcdedit.exe in the same location (it can be found in C:\Windows\System32).

The reason for putting bcdboot.exe in the same directory is because I have had one system where the WIM2VHD script failed when it had to call bcdboot.exe which certainly was present in C:\Windows\System32 but not found by the script.

Create the VHD and install the Windows 7 image:

cscript WIM2VHD.WSF /wim:S:\W7INS\sources\install.wim /sku:ultimate
/vhd:S:\MyDisk.vhd /size:50000 /disktype:Fixed

Note that the above should be one single line. I broke it up for page layout reasons. Make sure you keep a space between “ultimate” and “/vhd:” up there.

The VHD will be created as a 50GB fixed size file as S:\MyDisk.vhd. If you wish to use a dynamic VHD you can specify Dynamic instead of Fixed for the disktype, or simply not specify the disktype (and have it default to dynamic). Also, if you do not have to specify the size a 40GB dynamic VHD will be created by default. Check the documentation on WIM2VHD for more information. After a few minutes your VHD will be ready and should contain a nearly completed pre-installation of Windows 7. But now you still need to make it bootable.

Making the VHD bootable:

First we need to get a new GUID for the boot option:

bcdedit /copy {current} /d "My New VHD Installation"

Copy the GUID that is shown and use it as a replacement for {guid} below to create the boot entry. Note that the [brackets] around the drive letter SHOULD BE there!

bcdedit /set {guid} device vhd=[S:]\MyDisk.vhd
bcdedit /set {guid} osdevice vhd=[S:]\MyDisk.vhd
bcdedit /set {guid} detecthal on

After doing all the above you should now have a bootable VHD that you can boot into for final configuration and setup. If you want to check what the boot list looks like, just use bcdedit /v on the command line. If at any time you need to remove the bootable VHD you can simply do the following. First check the boot entries using:

bcdedit /v

Look for the VHD file in the output and copy the GUID that is shown for it. Use it as a replacement for {guid} below:

bcdedit /delete {guid} /cleanup

The quick start outlined above should get your started with VHD’s. But it doesn’t end there. For advanced use you can use VHD differencing disks, mount VHD’s locally on the system, and basically have yourself an abstraction of your storage, the use of which will vary depending on your requirements.

For quick testing and discardable VHD’s I tend to go with the default 40GB dynamic disks but for performance and sustained VHD’s that I use as a more manageable alternative to multi-boot scenarios I tend to use a fixed size VHD, usually something in the range of 35GB to 120GB, depending on my purpose.

Instead of creating disk images for backup and emergency restore purposes I tend to just keep a copy of the VHD’s around and save myself the hassle of having to restore an actual image when all I need to do is copy a VHD back to its original location, if needed by overwriting the existing copy if it has been banged up badly duing some extreme development activities.

One of the benefits of native VHD support is that you can mount a VHD to a drive letter on your system and conduct maintenance and repair without having to boot into the OS on the VHD. I have found this to also be very helpful in testing various critical doomsday scenarios where an OS gets corrupted from the outside. I also use VHD’s as bootable systems on my workstations to deal with beta software that I would not allow to run free on the native system itself and would otherwise not perform too well inside a VM. Since many of these beta things in my case revolve around graphically and computationally intensive software you can understand why I would like to use the full resources of the host system, in particular graphics drivers and all the CPU’s and cores available in the system.

I can hear you thinking, why would I copy entire 100GB VHD files around while at the same time assuming that is why I have so much storage in the home office. Sometimes I do, if I want to be really quick about it. But the way I keep and store copies of VHD’s that were created with a fixed size is by converting the VHD file to a dynamically growing VHD file using Starwind’s free V2V utility. I select the VHD I wish to convert, I select what I want to convert it to, wait around for not too long, and that generates the VHD that I will “shelve” on the server or backup to long term backup storage, ready to be used and taken off the virtual shelf whenever I need it. Likewise, when I take a dynamic VHD off the virtual shelf I will use V2V to expand the VHD to a pre-allocated fixed size, again, to gain the maximum performance.

Starwind V2V is an extremely useful tool for anyone who frequently shares disk images between VMware and Windows 7 or Windows 2008 Server, Virtual PC, or the 2008 Hyper-V. It can convert VMDK (VMware) images to VHD and vice-versa, either as pre-allocated fixed size files or dynamically growing files, including support for VMware ESX Server and Starwind’s own IMG format that is used by their Starwind Server and Enterprise Server SAN solutions (but more about those next week, in another place).

Another thing that V2V will not help you with, but that should go without saying (even though I’ll make a note of it here anyway) is to share installed operating systems between VMware and Virtual-PC and/or Hyper-V. If you wish to share operating system virtual disks you should go the full route and use sysprep and properly administer the deployment process. This, however, goes a little beyond the scope of what I was writing about here.

If you want the short version of this post I’ll summarize; Input Director does most of what Synergy does, and a lot more. I’ve run both side by side for a while and have completely switched over to Input Director now. Synergy has been a faithful utility that I couldn’t have done without and thanks goes out to Chris for creating it in the first place.

One of the features of Input Director that I really like is that the layout of the screens and systems can be changed on the fly in the Master Configuration panel. With Synergy I often had to switch to a pre-configured file since I change layouts quite a lot when I’m working on different things at different times. By simply dragging around the visual location of the screens in the configuration panel I can make changes much faster and without any hassle. And I haven’t experienced any of the problems with Windows 7 either, which is, of course, a huge plus for Input Director.

In addition to that, slaves can be configured so they allow themselves to be taken over by any system or by system name, or IP and subnet. Because my “master” system is interchangeable it comes as no surprise that this is something I’m quite happy with. No more fiddling with, or swapping out, configuration files on the master and using a network based script control that stops/starts Synergy remotely while making changes to the registry of the remote systems to update the name of the master system they should listen to.

Another great advantage is that Input Director will run as a Windows Service on Vista and Windows 7 (with Synergy you’d have to use the “start at login” instead of “start at startup”) and slaves are immediately available at the logon screen.

One of the other things I had gotten annoyed about with Synergy is that it doesn’t play nice with my Wacom Intuos 4 tablet. When using it in absolute mode and hitting the top edge of a screen it would try and take control over the remote system at that edge and unfortunately would lock up the mouse cursor on the remote system. Again, this required me to use a different pre-configured file for the Synergy master system. With Input Director there’s an option to temporarily turn off transitions. You can get to it from the tray icon menu or assign hotkeys. That’s the way I like it!

There are some more complex configuration options for setting screen edge percentages in Synergy that aren’t supported by Input Director (at this time) which I did use to ensure that transitions would not occur along certain portions of the edges of screens but after having moved to Input Director and its option to not allow transitions near the corners I found that it didn’t take me long to get used to this. I no longer miss this particular configuration feature that Synergy has.

I recommend you have a look at Input Director and check out the plethora of other useful features it offers. I could go on and on about it but I figure that if it works for me and my elaborate multi monitor setup then it should work for almost everyone else as well. Shane Richards, the developer of Input Director, has done an amazing job.

Oh, I may have forgotten to mention, it’s free. So what are you waiting for?

What I’m using for my windows and layout management is the Window Layout Manager, or WiLMA for short (hey, as developers we’re allowed to invent a dozen new acronyms each day and we like that little perk!). For all the details you can visit the Window Layout Manager page I’ve added to the site or just click the image below if you want a larger click target.

I started out with some of Tomas Restrepo’s color schemes and made various alterations to fit my personal preference and style. Because a dark background allows for a better distribution of color, and choices for color, it was worth it to see if I could be pursuaded to join the dark side.

The result is that I am finding it very annoying and painful on the eyes. But not so much the color schemes using a dark background themselves, but rather the practical implications when using it while doing actual work. The dark background allows for better highlighting of code, no doubt about that, but in a practical situation I often have other applications running on the screens which include things like help files, CHM’s and PDF’s with developer documentation and API docs, Outlook, OneNote, Visio, and many other development tools, etc. and almost all of these applications will use a light or white background as a basis.

The eyestrain starts to set in after working for a few hours whereby you read through a CHM, move back to your code on the dark background, and repeatedly move back and forth between the various windows. The extremely frequent and rapid movement and changes between dark and light ends up feeling very bad on the eyes and as a result I feel tired after only a few hours of doing this.

It’s back to my custom color scheme that uses a near white (250,250,250) background instead. It was fun while it lasted, though!

A few resources to help you on your way, as they did help me:

• A guided tour of the Microsoft Command Shell by Ryan Paul
• The PowerScripting Podcast by Jonathan Walz
• The Windows PowerShell Team Blog
• The Wikipedia page on PowerShell (with more resources)
• The online PowerShell Owners Manual
• The PowerShell Guy (Marc van Orsouw)