Here is the long story.<\/p>\n
Hi! As you may already know we are working on the best .NET – ARIS<\/a> interface there is so far. It’s an interface that makes heavy use of an old C-Api, using interop and p\/invoke.<\/p>\n In Mid-December Benjamin found a very strange behavior that almost spoiled my Christmas. We had just release Version 1.1 when he called me: “Arisan<\/a> crashes with Vista64.” I was shocked. “And with Vista32 as well”. I felt annihilated. We had done so much testing with various versions of XP, Vista and it worked fine with any of those OSes.<\/p>\n After some testing I saw that ARIS didn’t deliver any pointers at all. That’s rather bad for an interface to C that uses pointer in every call.\u00a0 After one more day we had more evidence: We had switched to .NET3.5 and VS2008 some month ago and our old versions, that were compiled using the .NET2.0-compiler, still worked.<\/p>\n I was so terrified. The 3.5-framework should be similar to the 2.0-framework, just some (not so) little enhancements. A bug in the 3.5-compiler?<\/p>\n To provide a quick solution we re-wrote parts of the fancy 3.5-syntax, to make our newest enhancement compile with the 2.0-compiler again. That worked (at least we thought so) and we released version 1.1.1.<\/p>\n Then a very frustrating time began. We read articles over and over and quickly found this very interesting post<\/a>. The problems described there where exactly what we saw.\u00a0 So we followed the track of the nxcompat-flag<\/a> and DEP, but it didn’t lead us anywhere.<\/p>\n The C-Api we interface is well documented, but it calls hundreds of other components and one of them crashed deep inside an undiscovered country<\/a>.<\/p>\n We read pages of differences between 2.0- and 3.5-compiler, new compiler-flags (should have paid more attention here), any documentation we could find, but nothing seemed to help.<\/p>\n We had a feeling it could have something to do with Vista UAC, but we didn’t find any matching explanations to our problem. Being really desperate we started this thread at the MS forums<\/a>. As you can read there, no one could provide a solution that worked.<\/p>\n I was really sad, because the last thing I wanted to do was to switch the entire development of arisan back to VS2005. I got prepared for a very sad life from now on.<\/p>\n But five days ago my life turned to happiness again. One more time I started of by googling words like “.NET compiler 2.0 3.5 differences” and one more time I read the new features of the 3.5-compiler. This time I obviously paid more attention to the compiler-flags and read about the \/win32manifest<\/a> and \/nowin32manifest<\/a> – switches. I didn’t have much hope left, but tried to set the \/nowin32manifest switch.<\/p>\n It worked! Everything worked! The C-Api delivered pointers again. I tried switching the win32manifest on and off and a day later Benjamin confirmed my results. We had found it. But after a long time of suffering (for me it felt like half a year) we still were skeptical and thought we needed a deeper understanding of the problem.<\/p>\n Finally we had something to look for and quickly found valuable information on the great I’m just sayin’ blog<\/a>. The documentation of the switches helped as well, so here is a summary:<\/p>\n The win32manifest is not the .NET-manifest.<\/p>\n The win32manifest is part of the UAC (user access control). UAC was introduced with Vista as an answer to more and more security threads. One of its ideas is to keep malicious software from secretly starting to work. If you work with Vista you may have noticed a lot of dialogs that ask you for permission to run certain programs. THAT is UAC.<\/p>\n Now the win32manifest inside an application tells the OS what level of permission it needs to run. There are levels like “asInvoker” (default), “highestAvailable” or “requireAdministrator”. In case the OS (and the current user) can provide the requested permission, the program runs as a trusted process (according to the granted access level). Of course, 90+% (just my estimation) of the programs on you Vista-machine don’t have a win32mianifest,\u00a0 because it’s a new feature and older applications just don’t have it. (And I think a majority of newer applications won’t have it either). In order to be compatible with no-win32manifest applications on one hand and providing security on the other hand, Vista can do a miracle called “virtualization”. It’s a bit like running a process in a sandbox<\/a>: Vista provides anything the process may need to run: disk space, memory, a registry etc. So the process feels cosy.<\/p>\n But anything provided this way is separated from the main system. The process uses a copy of the registry, writes to a special parts of the HDD drives and accesses the memory in a controlled way (not sure about the memory thing…). For me this is a great achievement of Vista, almost magic. I can’t tell in detail how it works (mainly because I don’t have a clue), but it works good and doesn’t cost notable performance.<\/p>\n So on your Vista machine you have processes that run virtualized and others that run non-virtualized. “Non-virtualized” is also called “UCA-compatible” or just “compatible”, so I’ll adopt this wording here.<\/p>\nThe win32manifest and UAC<\/h3>\n
![\"image\"](\"http:\/\/www.ticklishtechs.net\/wp-content\/uploads\/2009\/02\/image-thumb.png\")
<\/a><\/p>\n