Blog

News and other things I find interesting

May

2012

Visual Studio 11 Express - No support for building desktop applications nor metro style enabled desktop browsers

Last modified: Sunday, May 27, 2012

Microsoft announced last week that Visual Studio 11 Express will not have support for building Desktop applications, by extension this also means that it will not have support for building metro style enabled desktop browsers.

The workaround is to install Visual Studio 2010 and use the Windows 8 SDK. This isn't a good solution, but it's even worse when you consider metro style enabled desktop browsers. This workaround won't work for metro style enabled desktop browsers that need the Visual Studio 11 compiler. The Windows 8 SDK no longer ships with a compiler of its own.

Firefox can be built with a configuration option to disable the metro bits, so you'll still be able to use Visual Studio 2010 Express to develop on Windows 8, but not if you want to work on Metro related things. In that case, you'll need to use a paid version of Visual Studio 11.

As we've seen with Visual Studio 11 though, who itself can't target Windows XP, this will eventually become a problem as Windows versions increase if no change is made by Microsoft.

I hope that Microsoft will come out with an edition of Visual Studio 11 Express for desktop development, because it hurts open source projects that want to develop for Windows 8 and beyond.

If you also think this will hurt open source development in the long run, you can vote to add support for desktop development back into Visual Studio 2010 Express. Vote it, tweet it, blog it, add comments to it.

Microsoft has previously claimed that it loves open source:

"We love open source," says Jean Paoli of Microsoft in a recent interview with Network World. "We have worked with open source for a long time now."

Actions speak louder than words, please show us.

Tags: mozilla firefox visual-studio windows8

Add a new comment | 2 comment(s)

Anonymous on Saturday, May 26, 2012 (06:05:31) says:

Long-term, have you considered migrating Firefox to build with a MinGW toolchain instead?

Brian R. Bondy on Saturday, May 26, 2012 (06:05:28) says:

We do have some contributors building that way but it's not currently the primary way people build. And our Nightly builds and tests all run with builds made with Visual Studio currently. That wouldn't help with the Metro related bits problem also.

May

2012

DirectX and XAML interop - Great feature, but not for metro style enabled desktop browsers

Last modified: Saturday, May 26, 2012

The Windows 8 Consumer Preview introduced a great new feature called XAML interop for DirectX applications. Since Firefox on Metro is a Direct X application, we took advantage of that feature.

Using XAML interop made the following things easier:

Platform integration features
Input related work
The appbar
Edge detection
Other areas where we would use XAML based WinRT APIs

We ran into a bug in Windows where our process would crash on suspend though. This bug was confirmed in Windows 8 and was expected to be fixed for the release preview. Unfortunately since then, it was decided that this functionality would not be supported for metro style enabled desktop browsers.

This doesn't cause us major pain, but does take some extra time. We need to backout the XAML interop support. I'll be working on doing that this weekend, and expect to be finished by Monday.

We are currently using XUL for UI, if we ever did decide to switch to native UI like Android did, then this may be a problem. The appbar support will be reimplemented in XUL.

Tags: windows8 xaml directx firefox mozilla

Add a new comment

May

2012

Important change to UAC when disabled with process integrity in Windows 8

Last modified: Saturday, May 26, 2012

User Account Control (UAC) is a security enhancement in Windows introduced in Vista.

It makes applications that run by administrators, by default, only have access to what limited users would have access to.
Another way to say this is that applications run at medium integrity level by default.

If an application needs more privileges, it need to request it, and Windows will show a UAC dialog. If you press Yes to elevate on the UAC dialog, the process is said to be running as a high integrity process.

UAC can be disabled, and when it is, applications in Windows Vista and Windows 7 run as high integrity processes by default.

This changes in Windows 8, if UAC is disabled, your applications will no longer run as a high integrity process, they will run as a medium integrity process.

Applications can request elevation to a high integrity process when UAC is off explicitly and no UAC dialog will be shown.

We first realized this in Firefox because we noticed the update service was being used for all updates in Windows 8, even when UAC is off. We designed the update service to only use the service when UAC is on though.
So this change broke that design choice, and to fix it we need to check if the process is running on Windows 8 and if UAC is off.
If those conditions are met we would elevate our process which would not produce a UAC dialog.

Overall this is a great change by Microsoft though. It makes Windows more secure when users disable UAC. It's good to know about if you develop software for Windows.

Tags: firefox mozilla uac windows8

Add a new comment | 5 comment(s)

André on Saturday, May 26, 2012 (06:05:05) says:

Moving the UAC slider to the button no longer disables UAC in Windows 8. UAC is still on! This was done because Metro apps CAN'T run if UAC if OFF. If you disable the EnableLUA setting in the registry UAC is off and you have full admin token but all metro apps can't be launched.

Wladimir Palant on Saturday, May 26, 2012 (08:05:14) says:

Could you expand on the last paragraph? I fail to see how this change improves security. Sure, a process that has been compromised (buffer overflow or whatever) won't have highest privileges automatically. But if UAC is off it will be able to request them at any time nevertheless. Effectively, it's the same situation as in Windows 7 with UAC off, only one more step required. And I don't see why malware authors would be afraid of doing that step.

Neil Rashbrook on Saturday, May 26, 2012 (11:05:26) says:

Why does it matter whether you use the service or a free elevation?

Ian Thomas on Saturday, May 26, 2012 (11:05:51) says:

Aren't they basically just removing the ability to turn off UAC? Presumably they can afford to do that now applications have learnt to deal with the UAC restrictions, whereas if they had done it when they launched Vista then lots of applications would have been incompatible.

Brian R. Bondy on Saturday, May 26, 2012 (01:05:24) says:

> Could you expand on the last paragraph?
> I fail to see how this change improves security.

It's better to have your non malware process run as medium integrity. Sometimes things can be exploited where arbitrary code cannot be executed, but there is still an exploit to be had.

That's a good point though that if you can run arbitrary code through the exploit, then they are equivalent.

> Why does it matter whether you use the service or a
> free elevation?

Security has asked that we only use the service when we need to so that updates only run as SYSTEM account when needed. Personally I think it's the same since any admin can install a service and start it which would run as SYSTEM account. Free elevation is a new concept though only introduced in Windows 8 so this hasn't been discussed explicitly.

Maybe the second sentence in the above answer to the previous question is a reason why it's better to run the process only as SYSTEM when needed, and I think that's what security would say.

> Aren't they basically just removing the ability to
> turn off UAC? Presumably they can afford to do that
> now applications have learnt to deal with the
> UAC restrictions

In a way but this run as medium with free elevation concept is new. So whether you call that the new disabled or the new level when not disabled is up to you :)

May

2012