Comments

@felix9: AppContainer is a bit of a misnomer. The kernel name for AppContainer is "lowbox", and all of the security provisions of AppContainer are available to normal apps as well.

In fact, IE10 on the desktop runs as two processes (as it has since IE8); the low "rendering" process which always used to run as "Low-integrity" on Windows Vista and above now runs as "AppContainer" on Windows8, even though the renderer is not an app.

Although not formally exposed and technically subject to change without notice, you can create your own AppContainer processes via ntdll!NtCreateLowBoxToken API, which you can use to create appcontainer protected desktop apps by using it as the user token to advapi32!CreateProcessAsUser.

HTH.

Let's also not forget that up until now, a lot of the benefit of metaprogramming has been taken by ever increasingly clever compile-time optimisations.

For example

if(sizeof(void*) == 4)
  Do_X86()
else if(sizeof(void*) == 8 )
  Do_X64()

behaves as a static-if in Visual Studio's release builds, because the compiler is smart enough to see that the condition can be determined at compile-time and the unused branch can be removed.

Similarly (3 * foo) typically becomes ((foo << 1) + foo) in release builds to avoid the multiply - something that other programming languages might try and do by having a meta-programming multiply_by_constant that is clever enough to know tricks to avoid performing multiplies on the hardware.

Meta-programming is certainly interesting from a language perspective, but without a good grounding in compiler theory, it's easy to overstate its important from a performance perspective.

Regards the 32-bit/64-bit thing - lots of sysinternals tools do in fact require running the 64-bit version - for example procexp and procmon come to mind, as well as other utilities that require loading temporary drivers into Windows.

The reason you probably haven't noticed is that the 32-bit version of these detects that it's running in WOW64, and so silently drops the 64-bit procexp64 or procmon64 to disk and launches that as 64-bit.

This means that although many sysinternals tools aren't really 64/32-bit agnostic, they pretend to be in a way that is pretty clever.

RE: Rebooting takes too long. How to troubleshoot.

ALAKAZAM! I give you Mark Russinovich:

http://blogs.technet.com/b/markrussinovich/archive/2012/07/02/3506849.aspx

Btw, here's a shout out for a new Windows Update optional extra that appeared this week without much fanfare, and that most people won't have noticed:

http://support.microsoft.com/kb/2694771

It changes your desktop wallpaper every day to a random Bing wallpaper. To install, just open Windows Update and select it and install from the Optional Updates.

It's worth clarifying the point on whether "your software needs to be built for PAE" and from previous comments on last weeks show:

Firstly, let's be clear: AWE is not PAE. The first is about having more than 4GB of data in a process. The second is about having more than 4GB of RAM in a computer. (http://blogs.msdn.com/b/oldnewthing/archive/2004/08/19/217087.aspx). You can use AWE without PAE, and you can use PAE without using AWE.

Secondly, unlike AWE, PAE affects only things that look at physical addreses, i.e. some kernel mode drivers and the memory-management in the kernel itself - it doesn't affect normal user-mode programs. Consequently, to use physical memory above 4GB on a 32-bit system, only your kernel and some of your drivers need to be PAE aware - i.e. the ones that allocate physical addresses but foolishly assume that the physical addresses are 32-bit (physical addresses are actually 56 bit, just to be confusing). This truncation is the reason why 32-bit Windows chooses by default to ignore physical memory above 4GB and why it is disabled for Client SKUs.

You also need to be running the PAE version of Windows Server. There's a flag in boot.ini (or bcdedit) called /PAE, but this has been enabled by default ever since XP SP2. On a side-note, PAE is a requirement of hardware-DEP, so if you have DEP enabled, PAE is enabled. It's also a requirement of Windows7, so if you're running Windows7, you've got PAE.

Here's a good summary for the insanely few of you that actually care: http://superuser.com/questions/367490/can-a-32-bit-os-machine-use-up-all-8gb-ram-20gb-page-file

Anyway, all that said, unless you've got a really good reason not to, you should be moving to a 64-bit OS. That way all of these complicated things just work and you don't have to think too hard about it.

Physical memory not available above the 4gig limit because it's not addressable?

Orly?

http://en.wikipedia.org/wiki/Physical_Address_Extension

Apr 02, 2012 at 5:30 PM

Besides that I am not yet convinced that NET languages can't drive at the pace of C++. I blame the JIT compilers!

It's usually the GC rather than the JIT compilers that cause the slow-down, although even that is pretty small now.

Microsoft had a new one in queue, called "Phoenix". No word about it, sadly, in any recent events. C++ goes through Phoenix just like your C# does.

Phoenix is a unification of all of Microsoft's compilers. It's there in VS2011.

Mono and Java are already ahead performance wise.

Citation needed.

Hi Zura,

The Software Engineer in Test career is only boring if you want it to be - and lots of really senior developers at Microsoft have at one point or another been an SET.

It's a bit like a battle of wills between the SETs and the normal devs; the dev writes some new code, and the job of the SET is to prove himself by finding the bugs in the code. The job of the dev is to not write the bugs in the first place. As the developers get better at not writing bugs, the SET must get better and more ingenious at finding the bugs in the first place.

If you think about it, SETs have arguably a much more fun job than devs. They don't need to spend their life thinking about customers or features or compatability and upgrade paths and bashing out more code to comply with EU law. All they need to do is look at the code that someone else wrote, beat it with a stick and send back the mangled remains to the original developer with a note saying "I bashed it with a stick and it broke. Please fix".

Why run the Windows 8 Consumer Preview when you can run the Windows 8 beta - it's released on the 29th which is next week.