Written by Brad Wardell (Designer)
Once there was OS/2. In 1992, DOS needed to be replaced. IBM & Microsoft did battle to decide what would succeed DOS. Microsoft's direction was Windows. IBM's was OS/2. OS/2 lost. But from 1992 to 1996 it was clearly superior to Windows in virtually every way. And many ideas you see in Windows today can trace their origin to OS/2. This is important because it was on OS/2 that Object Desktop began its life.
No one knows who the first to "Skin" something was. But we do know that in 1995, Stardock, a young up and coming software developer released Object Desktop for OS/2. In development for 2 years, Object Desktop was truly a remarkable technological achievement. And it would go on to be the best selling OS/2-specific shrink wrapped package of all time. What Object Desktop did is allow people to enhance the OS/2 desktop to how they wanted it. In OS/2's case, it was usually used to tame the wild OS/2 desktop (called the workplace shell). IBM's view with OS/2 was to make it supremely flexible.
For this part of the history, it is important to remember the key year Object Desktop was developed: 1994. It was the time of Windows 3.1 and DOS. ZIP programs consisted of either very crude GUI programs or PKZIP on DOS. File management was the Windows File Manager or Norton Commander. Virtual desktops on DOS/Windows (or OS/2) were largely unknown. The more you remember the state of the PC in 1994 the more remarkable Object Desktop becomes.
Object Desktop added to OS/2:
An enhanced visual look (the term "skinning" had not been coined yet).
The ControlCenter with resource monitoring, virtual desktops, and program launching
The Tab LaunchPad which made it easy to organize your programs
Integrated ZIP into the actual file system. ZIP files behaved like any other folder (yes, we were the first to do this).
A way to package your desktop into a single file or parts of it. Imagine on Windows being able to drag and drop your favorite program into a "package" and having all its registry and class registrations automatically handled seamlessly.
A Keyboard LaunchPad to launch programs, links, and groups of programs.
And hundreds of enhancements to the OS that were so seamless that many users would come to believe they were part of the OS.
As you look at these screenshots, remember, this is software that was written around a decade ago. Remember what Windows looked like?
Windows in 1993/1994.
Here you have Object Navigator, which was the included Stardock file manager. While today, this design is no biggie, in 1994 when it was developed, it was quite different from its contemporaries (Windows file manager and Norton Commander). On the left, you have 3D text labels, and the ability to change the "types" of icons (on OS/2 you could change individual icons but there was no easy way to change your default folder icon for instance). On the right you have Tab LaunchPad and on the bottom ControlCenter. And again, today, these things may seem like par for the course. But in 1994, GUI "docks" that monitored your system resources, virtual desktops, etc. were a very new concept. The bottom window has the "go back" button integrated into the title bar.
Here you have at the top the Keyboard LaunchPad. At the bottom was one of Object Desktop's most radical new concepts - ZIP files being treated like folders. Today, it's a no brainer, but once again, in 1994, before there were compressed folders or "Zip magic" or whatever there was ObjectZIP. ZIP files could be opened, the contents modified, deleted, etc. like a regular folder. To put things in perspective, the alternatives ranged from command line utilities to crude GUI zip managers.
Object Package is a component that still remains only on OS/2. Essentially, you could package up your desktop or part of it and transfer it to a different computer. Imagine being able to package Microsoft Office, take it to another computer, unpackage it and have all its registry settings and DLLs and such all taken care of.
Some of the other innovations were the customization of the OS's GUI. The title bars, scrollbars, etc. are "skinned" with something that looked a little bit nicer than the default OS/2 look. It also added a close button to the title bar (in those days, you had min and max buttons only). When you navigated folders, an arrow would show up in the title bar allowing you to go back (this is 3 and a half years before Internet Explorer 4 would integrate something similar into Windows).
Object Desktop became the most popular non-IBM product on OS/2. Machines that came with OS/2 already installed typically came with Object Desktop with it. And Stardock had more ideas on where computer operating systems could go. IBM asked Stardock's Brad Wardell to come to Austin to discuss what the OS/2 Warp 4 desktop should be. The result is that IBM's OS/2 Warp 4's desktop was simplified and a close button added (in the position Object Desktop placed it).
At the same time, Stardock released Object Desktop Professional version 1.5 and then Object Desktop 2.0.
Object Desktop Pro 1.5 added 3 revolutionary new features:
Universal File Viewing
Web spaces on the desktop
As with much of this history, the timing of these innovations is crucial. Today, the idea of having the web as part of the desktop seems straight forward. Windows 98 introduced Active Desktop. But Object Desktop Professional was developed in 1995.
Not only could you embed windows into the desktop, you could have advisors which were sensitive to which desktop object you clicked on.
One way Object Advisors were used was to allow large corporations (where OS/2 was mainly used) to expand the features of the desktop without having to do real programming.
Once upon a time, there were many different software companies who made word processors, spread sheets, databases, presentation packages, etc. As a result, working with a myriad of formats was a challenge. Object Desktop integrated the ability to read these documents into the OS. And it could do so on the file system level. This mean that opening a folder would assign the icon. The file extension didn't matter. You could name your file "IBM.LET" (for IBM letter) and it could determine what type of file it was and give it the proper icon. This was also useful when printing. Just drag and drop to your printer and it would print it out with the correct formatting even if you didn't have the application in question on your system.
In Object Desktop 2.0, Stardock combined its original folder design with Microsoft's Explorer design to create a new type of folder window. It also introduced Dynamic Interface Modules (DIMs) which was Stardock's dorky name for "Skins" back then.
Another shot of Object Desktop's features (everything on the page).
In 1997, Stardock began working on Object Desktop for Windows. But on Windows, Stardock faced two challenges. The first one is the age old question, "What is to stop Microsoft or some other huge company from just taking your ideas and putting them into their OS or bundling them with some massively popular program?" The second was the issue of the decline of the OS/2 market. The OS/2 market's decline was very rapid in 1997 and most of the well known OS/2 ISVs disappeared between 1997 to 1998 (or went to Windows). Stardock's challenge was how to pay for the development of Object Desktop?
The answer to both came in the form of the Object Desktop Network (ODNT). The idea was that instead of there being an Object Desktop 1.0 for Windows, it would simply be available as a subscription. Users would just buy Object Desktop electronically and get all the software already on there plus everything new for a full year afterwards. This, in effect, allowed Stardock to constantly update its software to evolve as Windows evolved. And secondly, it allowed Stardock to provide something to customers before it Object Desktop was fully completed. Thanks to the loyalty of its OS/2 customers, who had, like Stardock, switched to Windows, Stardock was able to afford to make Object Desktop for Windows.
But what would Object Desktop on Windows have?
OS/2 was a wonderful operating system. Powerful and flexible beyond its time. But it was, by default, chaotic. IBM essentially said, "Look at all the stuff you can do with it! Good luck!" and the result was a fairly chaotic way of working. It was up to each user to put together their own way of working. What Object Desktop did, in effect, on OS/2 was organize and harness the power of OS/2 in ways that fit the way most people used their computers. As Infoworld once put it, "Object Desktop is like a third party upgrade to the operating system."
On Windows, the challenge was the opposite. Windows has a very concise design. Microsoft's philosophy has tended to be about trying to see how people use their computers and then create a singular design that satisfies the vast majority of them. A sort of "one size fits all" solution. Therefore, on Windows, Stardock's goal was to make Object Desktop a suite of components that would allow individuals and corporations to customize and personalize Windows. Most users would only use a tiny fraction of what Object Desktop could do. How much of it they used depended largely on how much they felt the Windows environment needed tweaking to match their needs.
In the 1997 design specification Stardock came up with these components:
A component that allows people to apply DIMs (later renamed skins) to change the look and feel of Windows. (This would become WindowBlinds)
A component that changes all the icons at once (this would become IconPackager)
ControlCenter for Windows
Tab LaunchPad for Windows
A component that would add OpenDoc/Taligent-like features to the OS (later called DesktopX)
A component that could either extend the Windows Start bar or allow users to easily create their own Star bars (later called ObjectBar)
A light but more powerful notepad (ObjectEdit)
A program to add special effects to Windows such as 3D icon text labels, shadows under windows (later called WindowFX).
And of course, the program to manage all the actual components as part of the subscription (Component Manager).
But doing this under Windows would prove to be a huge task. Whereas on OS/2 most of Object Desktop was written by one person, Kurt Westerfeld, on Windows it would take a lot more people to develop it. The bar had been raised over the years and it is a lot easier to organize an environment (OS/2) than it is to customize it (Windows). Top developers from around the world became part of the team such as Andy and Ed Satori, Neil Banfield, Brian Harper, Alberto Riccio, Jeff Bargmann, Adam Najmanowicz, just to name a few.
In 1998, Stardock started working on Component Manager. The design was that Component Manager would talk to Stardock's subscription network called Stardock.NET. Internally, it was called the .NET strategy. The reason this is ironic is that Microsoft's .NET initiative didn't come out until 2000 (Microsoft's concept is somewhat different from what we had come up with, we don't want to suggest that Microsoft's concept was derived from ours, someone there was thinking probably the same thing we were -- .COM's were for products and .NET was for services).
Essentially, Stardock was becoming what might have been the first "application service provider". Object Desktop Network (ObjectDesktop.net) would be purchased for $49.95 and that user would have an active account for a year where they could use Component Manager to download more components or update existing ones. At the end of the year, they could renew their account for an additional year at a reduced price. If they chose not to, they kept all the software they already had and could even order a CD (hard copy) of it to keep safe for future use.
All this seemed great on paper. But implementing it was a real challenge. In 1998, "eCommerce" was in its infancy. Creating a system in which you charged a credit card, sent an email to that user and then managed their account in a database that then could be connected to by a standard Windows program (as opposed to a web) was non-trivial then (nowadays there are all sorts of OCX controls, tons of server side software for eCommerce, etc.). In 1998, Stardock used programs like PMMail that would parse the email as it came in with custom written programs, then run other custom written programs depending on what was in the email that PMMail detected. Nowadays, any decent eCommerce software will allow you to connect to an SQL database (or heck, Cold Fusion, PHP or ASP can handle a lot of this stuff). But back then, things were much more primitive since your options on eCommerce were more limited. Just accepting credit cards over the Internet could be a pain since smaller companies like ours had a more limited set of companies we could work with and therefore we had to work with their systems which were often archaic.
With Andy Satori working on ControlCenter and Tab LaunchPad and Enhanced look on its way, things started to come together.
In late 1997, Stardock showed off the first screenshots of what it had:
This early "Enhanced Look" had many shortcomings that the later WindowBlinds would solve. For instance, just as on OS/2, DIMs were a DLL. Which meant creating them was a real pain. Especially if you wanted to do anything particularly fancy. Worse, some executable code was within them which meant that as the technology evolved, older DIMs (skins) were broken.
Here is the ControlCenter with Enhanced look in 1997.
BeOS was one of the first things Stardock & Nivenh wanted to try to make the Windows GUI be able to do.
And the first component Manager.
Things were particularly difficult with the enhanced look. Stardock's top developer at the time left Stardock to work at Microsoft. But before leaving he warned us, "If you think it's just mastering a single message like NC_PAINT you're mistaken. If you want to really change the look and feel of Windows, you're going to have to handle so many messages and go through so much pain that that it'll be virtually impossible to find someone willing to go through that much pain." Another Stardock developer said much the same thing, "Look, if changing the GUI of Windows were feasible, someone else would have done it by now."
Stardock also worked for awhile with one of the top developers in the on-line community called Nivenh who had similar frustrations. The issue wasn't just changing the Windows GUI reliably, it was doing it on multiple versions of Windows. It's not just an issue of talent, for Stardock's internal developers and Nivenh were immensely talented. The issue required talent & doggedness. That is, a tenacity to handle tiny things that require an almost super human attention to detail. And that's when Stardock met Neil Banfield who was working on his own GUI changing program. Soon after, Stardock combined its efforts with Neil's and the result was WindowBlinds.
WindowBlinds skins were simply a collection of bitmaps and a text file that described to the program where those pieces went. It also provided a skinning specification called UIS (User Interface Specification) that would allow skinners to a reasonably consistent way to skin the Windows interface as well as handle new features as they were added without breaking older skins.
By early 1999, Object Desktop was starting to shape into something recognizeable.
By release, Object Desktop felt somewhat complete. The ZIP functionality was not as sophisticated as it would later get but the skinning of the UI had become immensely popular with users. The ControlCenter's virtual desktops were a marvel and the Tab LaunchPad was still popular with users.
...And yet... take a look at the screenshots. They look so primitive still. In December of 1999, Stardock officially released the Object Desktop Network. That is, subscriptions would start to count.
The ability to skin scrollbars was a pretty big deal at the time (December 1999). It was, and still is, one of the features that the "free" version of WindowBlinds stand alone doesn't support.
By early 2000, Stardock was in the position of where Object Desktop did the "main" things that the OS/2 version did. Windows itself had evolved over the years to make some of Object Desktop's features from OS/2 redundant or simply weren't applicable. So it was time to start putting together the "new" stuff. The stuff that wasn't on the OS/2 version at all.
That meant that it was time for DesktopX. The concept from 1997 in which the long talked about Microsoft "Cairo" and IBM/Apple Taligent ideas would come together. And the release of Windows 2000 opened the door to the component that could make use of the new visual APIs to create WindowFX...
Today, a semi-transparent menu on a screen would be no big deal. But in 2000, it was new and cool.
WindowFX then added shadows to its list of features. It was the first program to allow alpha blended shadows on Windows. This was before there was a MacOS X incidentally (a long running issue with Stardock has been Mac fans retroactively crediting Apple or others with features Stardock came up with and implemented first).
And then DesktopX showed up. The pieces of Object Desktop were starting to really come together. See that notebook? It's an actual object with the parts of it being actual objects. DesktopX objects could do everything from tell you the weather to check out your stock quotes. And what made them special is that users creating the objects didn't have to be programming gurus. A user just needed to provide the graphics and then input what and when they would show up from a nice GUI interface.
One challenge Stardock ran into though was the timing. DesktopX was so flexible that users could create their own Start bars with it. But that's not what it was designed for. That's what ObjectBar was going to do but it wasn't out yet. As a result, there was, at first, a lot of replacement Start bars created using DesktopX. The issue isn't that DesktopX can't do it, it's just a lot harder.
Here things really get interesting. Look at the bottom screenshot, you see ControlCenter integrated into the actual Windows Start bar. Not done as a hack but as an actual ActiveX control too. Now this would not seem like a big deal, but in 2000 it was the first virtual desktop to do this (heck, hardly anything back then could be put into the Start bar).
For the 1 year anniversary of Object Desktop's launch, things had already come a long way. But 2001 was to bring the first big challenge to Object Desktop: Whistler...
And so there we were in late 2000, "We're king of the world!". Of course, such statements are made right before the iceberg hits. That iceberg was code-named Whistler. Whistler would deliver, either bundled or freely downloadable, a free virtual desktop program that could be made part of the Start bar. It put shadows underneath menus and allowed for some transparencies. Oh, and it had a new look. But to have a new look, Microsoft developed a pretty good skinning system that was remarkably similar to WindowBlinds (there were, by 2000, 3 different GUI changing programs including WindowBlinds, each took a radically different approach to changing the Windows GUI, Whistler's "Luna" took the same approach WindowBlinds did).
The timing of all this is key, because up until this time, Stardock's contact with Microsoft had been limited. We were, after all, previously an OS/2 ISV. I.e. we were "on the other side". But Whistler actually opened up a new era, a new golden age, for customization. And it's not thanks to Stardock as much as it was thanks to Microsoft. For Microsoft took the view that companies like Stardock were good for Microsoft. As a result, Microsoft would make Whistler (which became Windows XP) much easier to customize and personalize than previous versions. We also actively worked with Microsoft on skinning issues. In Spring of 2001, the alpha of WindowBlinds 3 was made available by Microsoft to its Whistler beta testers. It was the only third party program made available in this way (which caused a bit of a stir unfortunately and soon after had to be withdrawn lest Microsoft be in the position of having to put up everyone's utility). But it was crucial because it made it possible for WindowBlinds to work better by finding bugs and it allowed Whistler's developers to find out the limitations on GUI changing.
For one thing, it was decided that the format Microsoft had developed, called .msstyles, would be Microsoft digitally signed. Microsoft had found that third party ones created all sorts of problems and for those people who really wanted to customize their GUI, Microsoft could point them to WindowBlinds. In May of 2001, Stardock found a way to make third party .msstyles work without being digitally signed. The idea was that WindowBlinds 3 would allow users to use .msstyles or .UIS skins. But Microsoft asked Stardock not to release it (that's why when some people claim that Microsoft doesn't have a problem with hacks that disable digital signing protection we know that is not the case since we had already done this and were asked not to release such a "patch" - though in our case we used an API hook which has the benefit of working even if the version of the OS changes).
What happened though is that Windows XP turbo-charged the skinning community. Everything can be described as BXP and AXP (before XP and after XP). Before XP, Windows customization was a niche thing done by a relatively tiny community. When Windows XP arrived, it became mainstream.
In March of 2001, Microsoft had discussed "Luna" the code-name of the "Windows XP look". Stardock's Alexandrie created "PreLuna" which was our concept of what Luna might look like.
Another reason why Windows XP helped things is that it and ObjectBar arrived at nearly the same time. As previously mentioned, ObjectBar can modify or create its own Start bars. Nothing made creating your own Start bars as exciting as Windows XP did.
ObjectBar (which is what is doing that Start bar on the bottom) came out right when people wanted to make their own Start bars. Mainly it was non-XP users wanting to make their Start bars look and function like Windows XP.
By this point, things had also become a bit convoluted. So you wanted to have a "Whistler" desktop? Well, just load up WindowBlinds and change the skin to the Luna one. Then load up IconPackager and apply the icon set. Then set up ObjectBar to load the Start bar and get DesktopX to provide the nice alpha blended icons on the desktop and then change your wallpaper to a nice Luna one and so forth.
In short, Object Desktop was finding its way into only two markets: Tech savvy consumers who were willing to tolerate having to tweak a half dozen programs to get what they wanted. Or by corporations who used it to create a unique environment that never changed after it was set up.
This is where the idea of Convergence came from. Now called "WinStyles" on its own, Convergence was about applying all the parts together as a single entity. You would apply a "Whistler Suite" and WinStyles (Convergence) would then talk to the various sub programs seamlessly. You, the user, would never have to deal with the individual programs.
WinStyles, aka Convergence, opened the door for users to create unified desktop looks. You could create a "Suite" of skins and themes which when applied would take care of everything at once.
Rather than trying to compete with Microsoft on its own turf, Stardock worked with Microsoft and became a certified Microsoft development partner. This would become significant later on.
Object Desktop's goal has never been about "Eye candy". Even though eye candy is what many people use Object Desktop for, the real purpose is much bigger than that -- to let people decide how they want their computers to work. How something looks is part of that. But how it functions is equally important.
As a result, Object Desktop's integration in Windows became increasingly seamless. Users could build their own environments. Mix and match things from other operating systems to make Windows their idealized work (or play) environment.
But it was in 2002 that Object Desktop really became mature enough to be used by large corporations. One of the first companies to license Object Desktop was Microsoft who has used it to deliver customize Windows environments for their customers.
Microsoft's Xbox visual style allowed users of all versions of Windows to have an Xbox style to their whole desktop. Microsoft also used it for Age of Mythology and the new Rise of Nations strategy games.
Movie studios and TV shows had long used Object Desktop or parts of it to create those "futuristic" computer screens. In 2002 Stardock, Dell, and Touchstone Pictures teamed up on "The Recruit".
The computer screens in the movie are actually PC's running Object Desktop.
nVidia also is using Object Desktop along with its partners to present an nVidia desktop environment. In many cases, these environments are designed for dual use -- customers get a cool alternative look and feel and nVidia and others are able to integrate additional buttons into the title bar that can allow users to optionally get additional "stuff".
One of the biggest users of Object Desktop has been Nintendo who rewards its European customers who register products with the ability to download suites for their various games. There are now several different suites available. Here's the one from Legend of Zelda.
In the far off distance there is Longhorn. The code-name to the next version of Windows. And it will have features that will both challenge and excite the developers of Object Desktop. It has a new compositing engine that provides great power but will probably require great effort to fully utilize. It has a new file system for information management, and so forth.
But that's still a long way off and the good news is that Windows XP has lots of promise in it already and has much to exploit. But part of Stardock's on-going challenge has been to figure out how much money to spend on development and testing of components for older versions of Windows. For example, WindowBlinds 4 was released for Windows XP only. The version for Windows 98, ME, and 2000 had to wait because much of the enhancements in WindowBlinds 4 were because of features native to Windows XP. As a result, those OS features have to be created from scratch on previous versions of Windows. As time goes on, such efforts will be an increasing challenge.
When looking back at 1999's debut of Object Desktop on Windows, it's just amazing.
Where once WindowFX could just put shadows under windows and provide transparencies, now it can morph windows as you move them. And thanks to help from ATI and nVidia, there is virtually no speed hit on their newer drivers in doing so. Same for effects on minimizing and maximizing windows. To see it in action click here.
Another big overhaul has been the replacement of Component Manager with Stardock Central.
Remember how I mentioned how nasty it used to be to do eCommerce and manage accounts and just do updates to software? That was the world that Component Manager was born into. During 2002 to 2003, Stardock went back and reimagined how it would do things based on the latest technologies. This meant keeping track of update histories, documentation, message boards, chatting, etc. all from a single easy to use and robust environment. Stardock Central can look at your account in the Stardock.net database and figure out what parts you have access to and voila.
And then there is DesktopX 2. Part of the problem we ran into with DesktopX 1 is that unless you were going to do major surgery on your desktop environment, there wasn't a very compelling reason to run it. And even if you did, the whole thing seemed...well bloated. The UI was overly complicated and things just took too much work.
DesktopX to bundles a new feature called IconX. IconX lets you have full control over your desktop icons. In effect, this means that you can control what size they are on the desktop. You want 128x128 icons on your desktop and JUST your desktop? IconX can do that. If you want to have shadows under your icons, it can do that too. And if you want the icons to glow when you put your mouse over them or grow and shrink or play a sound, it can do that too.
The idea is that if DesktopX 2 can do something that even casual users would want, then it'll pave the way for users to slowly grow into extending their desktops more and more. DesktopX has always had memory compression so it's always used very little in system resources. Combined with a simplified user interface, Stardock hopes it will become much more popular.
There's also Keyboard LaunchPad which allows people to control programs, launch programs, websites, and perform system commands with any hotkey they choose.
If you do a search on software that customizes your system here's what you'll get: "Yea, I tried <widget A> and it was neat but it slowed down my my system to a crawl." (it's always to a crawl by the way apparently). History is difficult to get around. In 1999 and 2000, this kind of software made quite an impact. But in the AXP (After XP) era, the impact in performance on a modern system is relatively small. There are still people out there who will say "What? WindowBlinds uses 2 megabytes of memory? I'll tell you that in 1985 my Amiga could multitask 3 programs including a game in 512K of RAM..." But today, 2 megs of RAM is relatively little. But in 1999 and 2000, it was a different story.
Much of the effort in performance has been in adding features without using more memory. But starting with WindowBlinds 4, Stardock really began to put focus into making Object Desktop perform better, in some cases, than a system that didn't have it. WindowBlinds 4, for instance, uses hardware acceleration so that its visual styles (skins) run nearly as fast as an un-skinned system.
But where the big speed increases of the future will likely occur is in the MCP (Master Control Program). Stardock's long term goal is for all desktop enhancements to talk to the MCP and it would be the traffic cop when it comes to divvying out system resources. Even third parties would be able to make use of it. So when it comes to booting your system or loading up a bunch of various programs that personalize your desktop, the result would not only be seamless, i.e. as if they were part of the OS itself, but they wouldn't each have to reserve "System hooks" and such. They could share some of the same resources as one another and hence be even faster than they are today.
While on a high end system, these changes won't make much difference in perceived performance. But eventually Windows XP and its successors will find themselves increasingly used on embedded devices, tablets, and other types of hardware where the horse power isn't quite as impressive as today's desktop. Plus, part of the goal is to make Object Desktop a performance enhancer too. That is, not only would it add features to the OS to increase productivity but it would actually improve your overall system performance by optimizing the way Windows works. But that's all still to come.
Stardock was incorporated in 1993. 2003 marks Stardock's 10th year anniversary. Object Desktop on OS/2 began development in 1993 and was released on OS/2 in mid 1995. It's goal has essentially stayed the same, to use Infoworld's quote again, Object Desktop really is a "third party upgrade to the operating system". What the second decade of development holds no one can be certain. But Stardock hopes to continue to deliver technologies that will be common place in the future years early.
Brad Wardell is the founder and CEO of Stardock Corporation. He was the Product Manager of Object Desktop on OS/2 and on Windows. He is also the lead developer and designer of PC strategy games such as Galactic Civilizations (now at stores), The Corporate Machine, and The Political Machine (coming soon). His home page is http://www.joeuser.com. Stardock's home page is http://www.stardock.com. Object Desktop's home page is http://www.objectdesktop.com.
If you would like to purchase Object Desktop go here.