Turning off Data Execution Prevention (DEP) for IE7 on Vista x64

Time flies so fast that you dont even realize you have not written a new blog entry in a very long time...  

In January of 2007, I posted a comment to a security blog relating to the difficulty in turning off DEP in the 32-bit version of Internet Explorer 7 on a Vista x64 OS.  As to why you would want to do this, I will offer no opinion and would not recommend it in general for long term use.  However, lets say that your 32 bit IE (on Vista x64) opens and immediately crashes for some reason.  This means you need to tweak settings (like removing an add-in) for the 32-bit IE, yet the control panel only offers the 64-bit IE settings. Normally, you can get to the 32-bit settings from inside a 32-bit browser instance but due to the immediate crash this is not possible.

A very astute individual came across my comment and since comments were closed on the initial post, sent me a how-to guide for accessing the 32-bit IE settings in Vista x64.  I offered to re-post the details here with attribution.  Kudos to Razvan Socol, a SQL Server MVP, for providing this solution after encountering the same problem (after "blindingly following the advice in the Security Advisory 961051"), which makes this post fairly timely in case someone else falls into this trap:

To access the options for the 32-bit Internet Explorer, I started an elevated command prompt and executed C:\WINDOWS\SYSWOW64\EXPLORER.EXE /SEPARATE to execute Windows Explorer in 32-bit mode. In this window, I navigated to the Internet Explorer icon on the desktop and by right-clicking it, I accessed the Internet Options for the Internet Explorer 32-bit, where I could finally uncheck that box.

 

I'd like to post a comment on Michael's blog to share this info with the world, but the comments are closed for that post. Anyway, I thought at least I should let you know on how to solve that problem, although I'm sure you have solved it in another way by now... [ed: I actually did not find an easy way to do it previously outside of several registry tweaks]

Software Product Lines

This is the first of a series of articles on an approach to systems architecture called “Software Product Lines.” To introduce the concept, let’s ignore the word “software” for now and focus on what a product line is in a more general and tangible fashion.

If you are in the market for a laptop and go to Dell’s website, you have a choice of several different base models that can be configured to your specification. Once you select the base model, you can configure things such as the size of RAM, size of the hard drive, type of display, etc. What makes this possible is a hardware architecture of various components that can fit into the same slot – compatible electrically as well as physically. This allows Dell to create and mass produce (or purchase) several standardized components and simply plug them together to create a customized product at a reasonable cost in a short timeframe. When new technologies come out that require changes to the base product, like ATA laptop hard drives, Dell spins up a new product line with that one modification reusing the old technology and components that is still valid, tried, and true. This sounds like a great idea and solid common sense, doesn’t it?

As with anything, there are challenges to this approach. Take for instance a design flaw in one of the more heavily shared components, such as the motherboard, where the power connector solder joints go bad due to heat and constant plugging/unplugging. This one design flaw could end up costing dearly in repair and possibly recall expenses, as a significantly higher number of devices are impacted then if the system was not as modular. It is also significantly more difficult and time consuming up-front to design, build, and test a system that shares components. In a product line, tight adherence to specifications needs to be considered for future compatibility. Take for example the wireless network/Bluetooth riser cards found in many laptops. Let’s assume the bus timings are just a hair off spec, but the current crop of hardware is tolerant of it. Newer technologies coming out six months later may not be tolerant. A non-product line approach would be to make a revision of the entire system – which is required anyway; however, the product line approach requires significant expense to revise and test one or both of the components to assure compatibility.

Software is not very different than hardware when it comes to product lines. Most high-end software packages are heavily customizable so it can integrate into a variety of environments. Microsoft’s SharePoint product is one example, SAP is another. These two products are off-the-shelf packages intended to appeal to a very large market. There was heavy up-front investment by the vendor in design, documentation, interfaces, components, external training and certification programs, and more. But what if your product is very specialized with a small market? Even worse, what if your product is designed for small to medium sized businesses that typically can’t afford or will not have the resources to self-customize such a vast system? To top it all off, certainly, you cannot afford to invest in the amount of up-front work required to build, test, and debug a heavily customizable system given the small size of your target market.

Enter the concept of Software Product Lines. It is important to note that this is an engineering approach to solve a specific business problem. Using the Software Product Line methodology in a business environment that is not controlled or the problem domain of the customer is not well understood will cause you to paint yourself into a corner with no easy or cheap way out. Another salient comment is choosing this approach should not significantly change your development methodology (assuming, of course, that you have adopted a legitimate methodology in the first place). Finally, this approach is NOT a method of implementation, merely a way of thinking from a design perspective of what needs componentized. The decision to use a Service Oriented Architecture to implement a Software Product Line is off-topic – these are two different animals entirely.

Part II of this series will delve into some of these concepts deeper.