As someone that’s been using both C/C++ and .NET extensively over the past years, I found there was one very important point that Sutter glanced on, danced around, and did everything short of actually naming in his talk and it’s that if you’re doing anything remotely intricate or complicated, leaky abstractions in managed languages will bite you in the ass, and end up lowering your productivity, some times (and if what you’re working on is truly complicated, often times) to a point where you’d have been more productive using C or C++ in the first place.

The concept of leaky abstractions isn’t anything new and I’m hardly the first to point out how it can turn a knight in shining armor into a harbinger of doom and destruction. It’s the number one problem fundamentally present in almost any framework, but even more so in managed languages where the framework is all you have, and you’re not allowed to side-step it and build your own foundations to work with (p/invoke and interop aside). But lately it’s becoming more and more of a problem as the “push” for innovation that Sutter speaks of has become a fundamental requirement in just about all corners of the industry.

5 years ago, few in the .NET community could tell you what p/invoke was and how you’d use it. Now, it’s considered fairly basic knowledge and a working familiarity with the underlying C WIN32 API is a must for any desktop software developer looking to make a memorable, high-performing product in the world of .NET. Pretty much each and every WIN32 API documentation page on MSDN has a comment from someone on how to import that particular function into .NET with an interop definition, and people are running into the limitations of the managed framework far more often than they used to.

I’m still a big fan of .NET in general as it makes it really easy to quickly jump from idea to prototype to finished product for quick, one-off applications or basic tools and utilities. Even for huge products and projects, .NET’s GUI tools far exceed any C++ offerings in terms of ease-of-use and even functionality when it comes to having standard controls and features a single click away. But the leaky abstractions in .NET are proving to be a real pain in the back, and sometimes even interop just doesn’t cut it for the most trivial and basic of things.

Recently, I hit a wall with .NET in attempting to make EasyBCD support the parsing of internationalized BCD output in the form of bcdedit’s stdout. bcdedit, like many other Microsoft tools and utilities, is only UTF8 or Unicode aware if the console codepage is explicitly set in the application’s console window. I spent an entire day trying to shoehorn this functionality via various .NET hacks and failed interop attempts, a week off-and-on testing and debugging my various incomplete solutions, and in the end my solution was to create a C++ “proxy” application that would create a console, set the codepage to UTF8, run the command line utility, and pipe the output back to the host (source code here, MIT license: UtfRedirect). It was a guaranteed fix, took all of half an hour including testing it on 4 different platforms and experimenting with various internationalized stdout texts.

I personally believe the “best” compromise for medium-sized projects is to use C#/.NET to create the GUI and small helper scripts/utilities, but to build the core in C++ with an exposed C API or commandline interface. The short and long of the matter is, making a language truly and properly productive is a lot more work than just providing a sandbox with prettied-up API calls. You have to organically add improved productivity into a language from the bottom-up, making sure that the productivity goes hand-in-hand with power and flexibility, that it always second fiddle to being able to get the job done; after all, what use is a one-liner code if no mater how you twist and turn you can’t get it to do what you want?

While each of these fine web browsers has its own way doing things, ranging from keyboard shortcuts to tab management and process handling, they all more or less pull these off a bit nicer than Internet Explorer ever code. But the one Internet Explorer feature I can honestly say I miss when using Google Chrome is the ability to submit the form being currently modified/filled-in with a keyboard shortcut, especially if it works even if there are multiple forms on the screen.

Searching about for a cross-platform solution to this problem, perhaps a previously unknown keyboard shortcut or else some method of assigning a keyboard shortcut that would let Google Chrome intelligently submit the current form via a keyboard shortcut on both Mac and Windows, it became clear that this feature just doesn’t exist for Chrome. Well, as of yesterday, at any rate…

As of today, this feature does exist and it can be yours by just installing Chrome Form QuickSubmit, a Google Chrome extension that will add the keyboard shortcut alt+shift+s on Windows/Linux and cmd+shift+s on Mac to your Chrome, letting you easily and quickly submit the form you’re filling in without needing to resort to tabs, or gasp the mouse:

Google Chrome QuickSubmit 0.2

Again, the keyboard shortcuts are alt+shift+s on Windows/Linux and cmd+shift+s on OS X. These shortcuts do not, to the best of my knowledge, conflict with any others and there aren’t any known issues with this extension. So go ahead, click the link above, authorize the extension, refresh this page, and test it out in the box below!

However, there are a few things that have forever irked us about the ln lookalike called mklink.exe:

• It’s called mklink and not ln. (I mean, you just get can’t get around that fact)
• The arguments are switched around. `mklink something_doesnt_exist actual_file` is just…….. wrong!
• By default, mklink will create softlinks and not hardlinks. ln requires the /h flag to create a hardlink.
• mklink isn’t smart enough to distinguish between files and folders. You need explicitly tell it via the commandline.
• Even then, mklink has two different switches depending on the type of directory link you want. /D for softlink’d directories, and /J for hardlink’d directories.
• mklink can’t be used outside of cmd.exe (such as in PowerShell). (Hat tip: Jason)
• And, of course,  mklink isn’t open source.

So we made our own.

ln-win is available in 32-bit and 64-bit, uses the same syntax, names, switches, and argument ordering as ln on *nix. And pursuant to our promise to contribute more to open source, ln-win and our Junction Point library is 100% open source, freely licensed under the generous terms of the MIT license.

Perhaps more importantly, ln-win contains an open source Junction Point library. While Win32 APIs exist to create symlinks (on Vista and up), there is no API for creating hardlinks of any kind (for files or folders). The NeoSmart JunctionPoint library provides the following APIs:

	bool CreateJunctionPoint(LPCTSTR origin, LPCTSTR junction);
	bool IsDirectoryJunction(LPCTSTR path);
	bool GetJunctionDestination(LPCTSTR path, OUT LPTSTR destination);
	bool DeleteJunctionPoint(LPCTSTR path);

As you can see, the NeoSmart JunctionPoint library provides all the APIs you need both to create and interact with hardlinks. IsDirectoryJunction can be used for both symlinks and hardlinks, making it a snap to make your code symlink/hardlink aware, letting you intelligently avoid cyclic paths and data duplication for any filesystem traversal needs.

Binaries for Windows x86 and x64

ln-win Source Code on GitHub

While a lot of these may prove to have little to no value to anyone, given how easy it is to make things open source thanks to github, there’s no real drawback to throwing them out there for anyone that may benefit at some unknown point in the future.

We have a couple of hundred miniature projects, test code samples, and other such content across a number of drives to sort through, and whenever we find something useful, this is our promise to the community to share it. To that end, we’ve set up a github repository at http://github.com/neosmart where we’ll be uploading the code, and from where you’re all more than welcome to check it out and contribute back.

Follow us @neosmart for notifications and info on new projects and libraries added to the github repo!

We’d previously finished the tutorials for dual-booting Windows 7 with Windows XP and with Ubuntu 10 (complete with picture-by-picture steps!), but now we’re getting started on the real meat: the technical details of just what exactly is going on behind the scenes. The normal OS boot process is one of the most complicated parts of an operating system with just one OS in the mix – with multiple operating systems, each that works in its own way, things get that much more complicated, and it’s always good to have a nice, illustrated guide to refer to.

The first part of the updated documentation is now available in the form of an explanation of how a dual-boot between Windows Vista/7 and Windows XP normally works, plus a NeoSmart exclusive: EasyLDR and its support for multiple top-level legacy NT entries without needing to go through a second NTLDR boot menu, a long-awaited feature that was finally added with EasyBCD 2.0.

EasyBCD Documentation: The Windows XP Boot Process

EasyBCD 2.0 features a number of exciting new features, but some of the most technically interesting details lie in the improved Windows XP support. Besides the linked article which explains the mysteries of EasyLDR and how EasyBCD accomplishes top-level Windows XP support, a large amount of research went into the creation of BootGrabber.exe, a command-line application that we wrote to automatically configure everything needed to set up easyldr or ntldr, complete with automated detection of all Windows NT – 2003 installations on mounted disks, the generation of a corresponding boot.ini/ebcd.00x file, the copying of ntdetect.com and boot.ini to unmounted and unlettered partitions, and changing the active partition.

Hopefully another article will be added really soon to the EasyBCD documentation explaining the powerful command-line features available to users in BootGrabber.exe, which may be accessed via the “Power Console” under “Useful Utilities” in EasyBCD 2.0 and up.

Microsoft Visual Studio 2010 has been officially released for 3 months now (to the day), and to be pedantic, it has also been available in beta form since October 2008. Its bugs not withstanding, Visual Studio 2010 been a pretty successful hit. Besides the huge improvements to the .NET language and platform, big on the list of features for C++ developers is basic support for C++0x (the next standard version of C++, with lots of new & revolutionary features) and plenty of IDE enhancements. Intel’s C++ Compiler is the industry-standard with regards to performance and optimizations, still doesn’t support Visual Studio 2010 or C++0x.

As numerous postings on the Intel forums indicate, a plethora of users are in pressing need of an update to the Intel C++ Compiler. Questions on the matter are brushed-off, with short and rather-useless replies such as:

“This question has been discussed several times recently. The first such integration would come in a beta version of icc 12.0, which hasn’t yet been announced.”

No one has seen neither hair nor hide of Intel Compiler 12, not in private form or anything else. There is no information on the Intel site to even indicate that such a release is forthcoming. And until that time, developers will have to either resort to using the built-in MSVC++ compiler or hold off on migrating to Visual Studio 2010 and C++0x. Despite the information floating around on the net, the Intel C++ Compiler in its latest incarnation still does not support certain integral parts of C++0x such as r-value references (N2118) such that even if you were to attempt to manually compile your VS2010 project from the command-line by modifying the Intel compiler command-prompt to use the VC10 toolkit (as we’ve tried to do), you’ll find that it doesn’t even support the STL library headers that ship with VS2010. And linking to/against the VC9 headers results in DLL-hell with no way out.

The bottom-line of it all is that Intel still, almost a year after Microsoft made available development builds of VS2010 to corporate partners and TAP members, does not yet have anything that C++ Developers can use to build their solutions using features proposed and adopted for the next C++ standard years ago. And, perhaps even worse, there has been no corporate response to indicate when or even if such a possibility will happen. Intel’s customer support have been extremely vague on the matter of VS2010 support, have issued no official public statements on the matter, and are going out of their way to make their customers unhappy. Thank you, Intel. We really appreciate it.

We’ll be following up some more on this topic from a technical side later in another article, but for now, an example that most of you are sure to have come across if you’ve ever tried to map network drives before:

This popup is shown at system startup if you have any mapped network drives to UNC shares which are not protected with a username and password. If you map a network destination that does require authentication, Windows will map the drive OK. To further complicate matters: this message is shown only when you startup from a cold boot! If you restart your PC (vs shutdown and powerup), it won’t appear.

Resolving the issue is straight-forward enough: just double-click on the network drive in My Computer and it’ll automatically, instantly, and silently connect. Which makes one wonder why Windows couldn’t connect in the first place.

Good question.

While working an update to Genie Timeline, I ran across this issue. Windows wouldn’t connect a mapped network destination at startup for some of our customers, meaning that our backup couldn’t continue (assuming you’re backing up to the network drive) until you manually intervened and opened the mapped drive yourself. Definitely not cool.

As an in-house R&D test, we attempted to manually re-establish the connection via the command-line. By running

net use Z: \\remote\path\

we were able to re-establish the “disconnected” network drive. But when we tried to implement this in code, we came across a funny issue. If you try to run this very early on during the logon procedure, it will fail with error code ERROR_FILE_NOT_FOUND – basically, it’s unable to contact the network path. The funny thing is, explicitly testing to see if we can connect to the network path [GetFileAttributes(networkPath)] doesn’t return any error. But Windows itself is unable to establish a connection. Using ‘net’ from the commandline was just a workaround for R&D purposes, so we turned to the trusty old WNetAddConnection2 function – and it too failed with ERROR_FILE_NOT_FOUND even though the network path both definitely existed and was perfectly accessible as a UNC location!

Attempting either of these techniques to establish a mapped network drive connection later on – say 2 or 3 minutes after logon – works just fine. As does attempting to establish a connection to a UNC path that requires authentication. Or attempting to connect to the network drive after a restart and not a cold boot.

In the end, we resorted to calling WNetAddConnection2 at timed intervals after startup if the UNC path is accessible and the mapped network drive is not. It got the job done, but it really does speak volumes when developers have to run through hoops to address issues that have been out 2 OS releases and 5 years ago. We have no such problems with Windows XP.

The reply turned out to be longer than I’d originally intended, so here it is as its own post.

I’ll try to be as objective as possible in this reply:

The most important thing for frustrated end users to keep in mind is that Mozilla/Firefox cannot be held responsible for cases where incorrectly written plugins and/or extensions cause Firefox to abuse system memory – that’s the trade-off between empowering developers and keeping the code squeaky clean.

Most of the cases reported are indeed caused by one or more extensions or plugins gone awry, doing something they shouldn’t be doing, or something they don’t know how to do properly. Some of the most popular plugins for Firefox are notorious for their memory leaks; but few users realize just how dangerous they can be, and that the Firefox devs cannot really do anything about it.

At the same time, there can be no doubt that Firefox has some memory leaks in the codebase itself. They’re clearly not easily reproducible and they don’t happen very readily nor often enough because the developers have clearly spared no effort in their attempts to address this problem for once and for all. But they’re there, nevertheless.

No matter how you look at it, the fact remains that under certain circumstances, doing certain stuff on certain machines in certain ways for certain people, Firefox still leaks memory. A lot. On Mac, Windows, and Linux. Yes, on clean installs too.

Now as a systems developer (Mac, Windows, and Linux w/ their respective native APIs; embedded systems; .NET and more with years of experience), I must say that of all the bugs and problems I’ve ever encountered, there is nothing that “cannot be fixed.” To say that this behavior is out of Firefox’s hands because it’s not their code that’s causing the problem is simply not true.

I’ve experienced memory leaks like this (and worse) in my own code in the past, largely due to stupid mistakes and silly oversights. It takes extreme persistency to make memory leaks go away – a willingness to spend 24 hours on-end & non-stop crawling through code, memory dumps, and stack traces to try and find out where things are going wrong. It requires remote debugging on allegedly-affected machines. It requires reading through dozens to hundreds of sometimes clueless users describing in the most general of terms what they were doing when things went wrong. In short, it requires a lot of effort and very little recognition and a hell of a lot of hair-pulling.

But it can be done.

C++ is an incredibly powerful language. If you know the code you’re developing and the systems you’re writing it for, there’s nothing you cannot fix. Dynamic memory allocation is the biggest gift/curse in the world, but in C and C++ if you can allocate something that means you can free it. Even if you don’t have a mechanism to find out where it is and how it got there. But you just have to be cunning enough to figure out how to track them down and set them free, taking care to know when and where to do so safely…. and you have to be familiar with every single routine and how they work; which is obviously extremely difficult with codebases as large and complicated as Firefox’s.

There are even workarounds for the memory leaks (assuming they can be isolated) if the developers aren’t willing or capable of doing the aforementioned. If you’re dealing with leaky libraries that you can’t fix, in the very worst-case scenarios you can hook into them at runtime, access the functions you need, reserve the memory required, get the job done, copy only what you need, then free it right back. All of it. You can have helper threads or processes handle this stuff then wipe them and their memory spaces clean when they’re done to complete the memory insulation.

There’s a lot of stuff that can be done, and none of them are easy. But the journey of a thousand miles begins with a single step, and developers and evangelists denying a problem exists isn’t the way to go about addressing the matter at hand.

At the end of the day, Firefox is a great browser and any complaints about its performance and its shortcomings are only out of a sense that it can do better – that it has to in order to remain at the top of its game in a cutthroat market of only the most intense of competition.

For a device that’s supposed to do Firefox, Skype and not much more, an underpowered PC with a touchscreen isn’t going to accomplish much. For one thing, Firefox is a huge performance drain and a memory hog to boot that underpowered hardware (even on-par with an Eee) simply won’t support and for another, there’s no way to get PC hardware down to the sub-$200 price range.

What TechCrunch wants – whether they know it or not – is an oversized PDA, not an underpowered PC. And it’s not just a question of semantics, it’s a question of foundations and principles – and it makes a huge difference in terms of end-user experience and the bottom line.

For the functionality that TechCrunch is trying to pack into this opensource, mass-market web gadget, there’s nothing that wouldn’t work better, faster, and cheaper on specialized hardware rather than on generic PC components.

While the world is now in the midst of a touch-screen craze, it’s important to keep in mind when and where that works. For a web browser and a VoIP client, a touchscreen doesn’t provide much added value, but it does add quite a hefty amount to the bottom line. A couple of buttons at the top/side of the device that provide basic functionality (Go/Dial, Stop/End) would certainly suffice for most purposes. A thin slide-out keyboard is far-cheaper and more user-friendly than an onscreen keyboard, and would make things like entering site addresses and using email clients and Google Docs quite enjoyable.

A PDA-style ARM processor, running software compiled for the ARM platform could provide a more satisfactory end-user experience with regards to performance and can come in smaller form-factors and/or as embedded systems.

It’s important to bear in mind the difference between consumer electronics and a computer. Whereas Asus had to keep their Eee x86 so that it can run whatever a a PC user could demand from it, a web browsing tablet only needs to run what the manufacturer intends it to. In hardware design, there’s a constant compromise between flexibility and complexity which is directly tied to price, size, and ease-of-use.

A tablet designed to surf the web and run Skype doesn’t need to do anything else; but it shouldn’t do anything else if price and size are of any concern. It’s easy to get caught up imagining a device that can do anything and everything; but you can only go so far before things begin to spiral out of control.

With this update the installation process has been simplified somewhat, in particular the need modify HTTPD.INI to set the server variables has been eliminated – you just need to install ISAPI_Rewrite 3, configure php.ini to load up request_uri.inc, and you’re set.

Request_URI for Windows 1.1 retains backwards compatibility with ISAPI_Rewrite 2.x for those of you who’d rather not switch to the new (and much-improved) version 3.x.

Download Request_URI for IIS 1.1

The full instructions for installing and configuring Request_URI for Windows can be found at the original posting. Please post any support questions in the forums.

NeoSmart Technologies is not affiliated with Helicon software in any way.

Facebook recently conducted a poll which showed up on the homepage newsfeed, and asked Facebook members just how exactly did they think Facebook’s “friend finder” worked when it prompted them for their email address & password in order to get a list of contacts. The numbers pretty much speak for themselves, here’s what they looked like near the end of the campaign:

Now ignore the dark blue bar: it’s a red herring and doesn’t contain any interesting info. The real juicy bit is the “Yes” option, and its 20% response.

20% of Facebook’s 80 Million active users (give or take) believe that the passwords for their email addresses are being stored when they use the Friend Finder…. and that doesn’t bother them in the least. That’s sixteen million people who don’t give a damn about their privacy, the contents of their email, or who has control of their entire online personas.

This is a subject that’s been chewed half to death already countless times by people far more in the know than myself; Jeff Atwood’s excellent article on the topic covers the dangers of sites asking for users’ email addresses & passwords, and – far more importantly – presents several more secure alternatives for web application developers looking to expand their social networks.

To put things in perspective, take a look at this downright horrifying tale on ReadWriteWeb about software that prompted users for their email addresses & passwords, then proceeded to save them for malicious use… then realize that 16 million Facebook users out there don’t care if this happens to them. Think about all the private, sensitive, confidential information available on your email account and just how truly terrible it would be for that info to fall in the wrong hands.

Of course all this begs the question: who’s to blame for this bout of end-user stupidity (for lack of a more politically-correct term)? Is it naïveté/trust in the goodwill of others that gets users to give out such sensitive data to people (Facebook has 500 employees!) they don’t know from Adam? Or is it that they just don’t get how dangerous it can be (see the ReadWriteWeb article for proof)? Or is it, maybe, that they’ve simply gotten accustomed to being asked for their email address and corresponding password by “trusted” sites they love to visit, too caught up in the “gather as many friends as you can” game to give a second thought to identity theft and fraud?

Personally, I can recall a time when most “normal people” I know would refuse flat-out to share such sensitive data with a site (phishing, tech support, etc. obviously excluded); but in the wake of “Web 2.0” it’s become so normal to ask for email addresses and passwords that no one ever gives it a second thought.

And it’s not just Facebook. To be totally frank, even if Facebook were to store end users’ passwords in their database, the access to that info would probably be very highly guarded… but when every new social network on the block is suddenly doing the same thing – you can get a good picture of just how easy it would be to steal users’ passwords.

MQ’s 3 Steps for World Domination

1. Send out an email purporting to be from “the hottest new social network around” informing the recipient that their “friends” want them to join: “Click here to show Peter you’re a real friend!”
2. Get the user to register a new account – make the procedure as pain-free and simple as possible… and right then and there on the registration page ask for the user’s email address and password so as to “make it easy to tell all your friends you care and get popular really fast…”
3. Profit.

As soon as it’s OK for one person to do it, it’ll be OK for everyone to… and then we’ll be in too deep to do anything about it.

So why does Facebook – after polling their end users and seeing just how dire the situation is – continue to use the same flawed mechanism of harvesting email addresses… especially when better, safer alternatives exist?

Memory usage: Several new technologies work together to reduce the amount of memory used by Firefox 3 over a web browsing session. Memory cycles are broken and collected by an automated cycle collector, a new memory allocator reduces fragmentation, hundreds of leaks have been fixed, and caching strategies have been tuned.

We’re sorry to have to break it to you, but if you thought it was too good to be true you were right. Firefox still uses a lot of memory – way too much memory for a web browser.

We haven’t seen it reach 1GiB+ like we have with previous versions, but it’s quite normal for Firefox 3 to be sucking up ~300MiB of memory right off the bat, without a memory leak (the difference between memory leaks and normal memory abusage is that in a memory leak you’ll see the memory usage keep increasing the longer the browser is open/in-use).

This is a screenshot of Firefox’s memory usage after just a half hour or so with only a couple of HTML-only tabs open. This particular screenshot was taken on Linux where Firefox is using the shared GTK libraries – on our Windows PCs, it’s normal to find Firefox 3 taking up ~350MiB or so on both XP and Vista.

The sad thing is that isn’t caused by one of the memory leaks that plagued previous versions of Firefox. It’s Firefox 3 is supposed to take up that much memory – at least, that’s our assumption given how we’ve never seen it take up less.

Firefox 3 has a number of memory-hogging features added to the mix that are probably at least partially responsible for the absolutely gargantuan memory footprint. For example, Firefox now uses an SQL engine to keep track of your history and bookmarks, amongst other things. While that particular feature is powered by SQL-lite, which should – in theory – not take up too much memory, we’re at a loss to explain what else is wasting memory left, right, and center in the world’s most-popular open source web browser.

Things like full-text on-the-fly searching of the web cache for when you type text in the address bar certainly have an impact as well – that’s a lot of stuff to keep in memory at one time. But Opera 9.5 does the same with a lot less memory, so obviously Firefox 3 is doing something wrong.

It’s a shame that Firefox 3 is on the verge of a release and is so terribly unfit to run on any machine – Windows, Linux, or OS X – with less than at least a couple of gigabytes of memory.

Whether or not MinWin is the very same kernel that went into Vista or not is officially unknown at the moment; but what we do know is that Shipping Seven is either one huge fake, or else that the Windows core programmers at Microsoft are so stupid that they don’t know the first thing about coding, kernels, operating systems and compilers.

The post at Shipping Seven is littered from beginning to end with fallacies, lies, and incorrect deductions that anyone with even the most basic coding skills would know better than to ever post, especially not when attempting to pass it off as the work of some of the more talented coders out there.

Here are some of the more-glaring factual errors in the post that completely strip Shipping Seven of any authenticity or authority it may have on the topic of Windows 7:

How many times has the Ubuntu or Mac OS X kernel been rewritten?

Correction: OS X is powered by a rewrite of the XNU kernel which is a modified version of the Mach kernel which, in turn, is a complete rewrite of the original BSD kernel. And, of course, Ubuntu isn’t an OS in and of itself, rather it’s just a distribution of Linux.

While it can be argued that not every developer at Microsoft is expected to have intimate knowledge of the inner-workings of other operating systems, no one in their right mind would believe that the Windows kernel programmers don’t even know what kernels their strongest competitors are currently using.

We spent a boatload of time during Windows Vista making everything ‘componentizable’ – So that we could (by creating some xml files that our build process uses) create a boatload of different versions of Vista (and Server 2008).

….

You already have MinWin – It is the core system components that Windows Vista needs to function; everything else on the system depends directly or indirectly on it. It is the last thing you could (theoretically) uninstall.

So, if you really really want it, you can get it, I suppose – you probably could (using the command line) uninstall almost every single Windows Vista system component, including the user interface. I don’t know what the hell you’d do with just a kernel and a kernel loader on your machine, though.

Assuming you can get past the way that the post was written (with references like “using the command line” which indicate a general lack of knowledge about computers in general; treating the command line as if it were a “god mode” that can be used to do just about anything), there’s still the matter of factual inaccuracies – and inconsistencies in the article itself.

You can’t change/modify/revert pre-build settings by running commands in the command line. Components that are integrated at compile time simply cannot be removed by running a bunch of commands afterwards – especially not from within the resulting OS itself.

Anyone that’s ever manually compiled a Linux kernel knows this. You can’t strip ext3 support from the kernel after it’s already built any more than you can add Reiser4 support to the kernel without re-building it. As a matter of fact, anyone who’s built anything at all should know this – the same rules apply to any other program as well. For example, you can’t remove PHP support from Apache if you’ve compiled mod_php directly into the binaries.

Shipping Seven is a big, fat fraud. It’s written by someone with only the most basic knowledge of computers, zero knowledge of coding concepts, and absolutely no experience with kernels and operating systems. Shipping Seven is most likely written by the equivalent of script kiddy, eagerly awaiting the first leaked builds of Windows 7 to appease an inner itch – most likely all the while lamenting his lack of involvement in the Longhorn beta. It isn’t worth the time it takes to read, and definitely doesn’t deserve even the questionable authority it now has on the topic.

One of the first thing Computer Science teachers drill into the heads of their students is that it’s important to map everything out beforehand. Design the algorithm. Draw the UML diagrams. Decide the entire flow of data and the relationships between everything before you even touch the IDE. While this is integral advice for anything above a small-complexity project, there is an exception: if you have a gut feeling, follow it.

For instance, the other day I sat down to write a simulator for a MIPS datacache, with different replacement policies. “Ideally,” the planning procedure would have involved designing the sequence diagram, a flowchart detailing the method used by the cache to determine expired entries, and generally-speaking a lot of time down the hole just visualizing what happens beforehand.

While mulling things over for a minute or two in my head to gather my thoughts, I found myself scribbling three phrases on the PostIt note in front of me:

• Access times -> FIFO
• Access times defined by unique tag
• Reading memory == dequeue item

These were spur-of-the-moment analyses of the caching procedure. Just thinking about the caching methodology brought these ideas to mind, with no particular “thinking through” of type. Looking back at them, I couldn’t (instantaneously) recall why I felt that access times should be removed FIFO from the data structure on read, but I figured it must have made sense on some subconscious level and plowed ahead right into the code.

In the end, the code worked, the project was done far quicker than originally imagined, and I had time to kill post this article.

Any good programmer you talk to will have a similar experience to share. The only reason I trusted my instinct in the first place on this matter (keeping in mind that the implementation of “random” algorithms can be a huge timesink if they don’t actually work) was because trusting my coding instincts has generally proved to be the right thing in the past – this is simply the most recent example.

Of course, every once in a while an impromptu idea may not be perfect; indeed, it’s possible that they’re fatally flawed. Whether it’s because the problem itself wasn’t initially understood or simply a matter of arriving to the wrong (hasty) conclusion, mistakes can (and have) occur. But it’s important to bear in mind the ratio of brilliant ideas to failures – most good programmers I’ve spoken to reaffirm that it’s a very workable hit-miss ratio.

Certainly programming by instinct has its drawbacks. For instance, these “strokes of brilliance” make up the majority of what we refer to – in retrospect – as quick and dirty solutions. There’s a time and a place for using them; and being unable to figure that part out can end up hurting you and your program. Typically speaking, using the first thought that occurs to you when structuring your program (what classes, how they interact with one another, etc.) isn’t such a good idea. Things like this need to be refined non-stop (until you get that warm, fuzzy feeling when you look at your code ;-) and quick solutions won’t help you there.

It’s usually within individual functions when you need to get something done based on the state of one or more other objects that instincts prove handy. To put it another way: when the code you’re working needs some measure of creativity and out-of-the-box thinking, don’t ever pass up on a gut feeling. Programming gives experience and insight, much of it subconscious. Patterns and ideas may leap out at you in ways that aren’t immediately obvious, but even if we don’t fully comprehend how the ideas came into existence it doesn’t mean they don’t have a substantial amount of intricate logic and supporting foundation to back them.

The next time an idea flashes into existence, like the proverbial lightbulb flickering on above your head, take a minute to appreciate its glow. Realize that you’re lucky to have such inexplicable moments, and trust them to take you and your code to the next level.

iReboot isn’t by any means a major application, but it’s gathered a pretty strong following over the months, mostly by people interested in boosting productivity (or increasing laziness) to the max. But there was one flaw in iReboot that made all the hard work we put into making it as unobtrusive and minimalistic as possible almost meaningless: if you had UAC enabled, iReboot will not run automatically at startup, no matter what you do.

This behavior comes as a result of the architecture that Microsoft used to secure Windows Vista, which doesn’t allow for applications requiring admin approval to run at startup. It doesn’t matter what your application does or if you absolutely trust it beyond the shadow of the doubt, Windows Vista simply won’t let an application that runs in elevated privileges mode to launch at startup – end of story.

Users of iReboot were quick to point out that this is a major drawback that made it almost useless – after all, it’s far less productive to have to manually run an application when you want to reboot than it is to wait for that startup screen to appear and select the OS you want. So we set about finding a solution.

We’ve just released iReboot 1.1, a UAC-free implementation that doesn’t require admin approval, elevation, etc. past the initial installation. And, yes, it does run automatically at startup too!

The Gory Details (feel free to skip below to the download links!)

In order for iReboot to be of any use, we had to get around Microsoft’s UAC limitations. For iReboot, it was of the absolute importance that it run at startup, and that it be allowed system access from normal user accounts. On Windows XP – where everyone runs as an Administrator and there are no annoying UAC prompts – it was a non-issue. But on Windows Vista, the new architectural requirements for running applications in elevated privilege modes made it near impossible.

While digging around for possible solutions, it became clear that the only possible fix would be to split iReboot into two parts. One would run in the background as a service, running under the SYSTEM or LOCAL SERVICE accounts and having privileged access to the OS without requiring admin approval or UAC elevation, and with the second half running as an unprivileged userspace client program which interacts with the service backend to get stuff done.

The resulting application has an installer – which requires admin privileges, of course – which installs and launches the background service. The background service has full permission to do what we need to get operating system XXXX to be the default option for the next boot, but – in line with the Windows Service Model – cannot be interacted with by end users.

The installer also adds a normal UI application which sits in the taskbar (from where end-users may interact with and use iReboot) and communicates with the backend service via a custom API which must not require the execution of any privileged code. The service can do whatever it wants (well, whatever we want it to do, but lets not get picky here!), but the client program must only perform actions which normal, unprivileged users have permission to execute.

By using a standard inter-process communication API we avoided the need for any special actions on behalf of the client application, effectively separating logic (residing and executing on the backend service, free from the many limitations of UAC) and presentation/design (the client application, bound to obey UAC’s every wish).

The Bottom Line

Anyone running Windows XP or Windows Vista – with or without UAC and/or admin approval mode enabled – can now run iReboot at startup and use it to boot into whatever OS they like (in conjunction with EasyBCD, of course!).

But getting this far wasn’t easy. With Windows Vista, what should have been 100 lines of code maximum ended up being a dozen times longer, split across two different processes, and requiring way too much man-hours to write the most minimalist and to-the-point piece of software we’ve released to date.

Perhaps most importantly though, is the fact that Windows Vista’s newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security. Any program that UAC blocks from starting up "for good security reasons" can be coded to work around these limitations with (relative) ease. The "architectural redesign" of Vista’s security framework isn’t so much a rebuilt system as much as it is a makeover, intended to give the false impression of a more secure OS.

With the current Windows Vista security models, Microsoft can claim that Vista blocks system-modification tools from running at startup; but the truth is, there are still many ways to get them to run. At the end of day, our experience with iReboot and Vista’s security implementations brings us to the sad conclusion that with Windows Vista, Microsoft has made ISVs’ jobs more complicated without actually providing any any further protection for end users from malware authors – which certainly isn’t the best way of going about this task.

Anyway, the fruits of our efforts:

Download iReboot 1.1 (248 KiB)

[support] [donate] [changelog]