The first four labs in a series of Windows Server 2008 Application Compatibility labs have been released on MSDN. You can find them as follows:
- MSDN Virtual Lab: Windows Server 2008 - Access Rights, Impersonation
- MSDN Virtual Lab: Windows Server 2008 - Impact of Code Signing
- MSDN Virtual Lab: Windows Server 2008 - Installer Detection
- MSDN Virtual Lab: Windows Server 2008 - Session 0 Isolation
There will be more labs in the coming weeks. Stay tuned and enjoy!
Hello, everybody, I have released the first version of a rudimentary managed wrapper around Transactional NTFS to Code Gallery on MSDN: http://code.msdn.microsoft.com/txfmanaged.
The wrapper in its current form is very basic but should give developers a good idea on how simple it is to use Transactional NTFS from managed code. Feel free to go grab it, play around with it (there are some sample screencasts using the wrapper on the Developer Meet Server Show), and feel free to use it any way you wish.
Enjoy!
Ray Ozzie has now made his Channel 9 debut, folks. In this video, being interviewed by Jon Udell, Ray discusses Live Mesh. From the Channel 9 description:
In his first Channel9 interview, Ray Ozzie, Microsoft's Chief Software Architect sits down with Jon Udell to talk about Live Mesh, a new technology and platform that enables synchronization and storage "to the cloud." You'll hear about the history of Live Mesh, how it has been influenced by Ray's previous work on products like Groove and Lotus Notes. Ray also discusses the core technology that forms the basis for Live Mesh including REST APIs, XML, and synchronization APIs that enable you sync your Mesh across multiple devices.
So make sure to tune in and watch the video. It's great to see this information coming out in public finally.
Jason Mauer and I are doing an Open Space session tonight @ 6:30pm in the Open Space Theatre at MIX 08. If you are a musician who happens to be a computer geek for a living, come on by, chill out, and enjoy. Hope to see you there!
Hey all, I will be at the wonderful Venetian Hotel in Las Vegas, Nevada this week working at the MIX08 conference. Drew Robbins and I are a couple of the guys "behind" Open Space @ MIX, so we will most likely be parked in the Open Space area most of the week. Feel free to stop by and say hello if you are at the event.
Originally, I was the owner of what used to be known as "MIX Chat" (usually referred to as "Ask The Experts" in Microsoft Conference speak), and Drew was in charge of Open Mic. Drew had the idea to bring in the Open Space idea into the conference instead of the old Open Mic method. When he approached me about the idea, I loved it and jumped in as well. So, now, there is no longer a "MIX Chat" this year as we are looking at integrating it more directly into the conference itself. I guess we'll see this week how it works out!
A new video has been posted to the Developer Meet Server Show on Channel 9. In this video, we discuss tools and resources you should know about when debugging application compatibility issues. From the description of the video:
"In this video, we sit down (well, stand up actually) with Chris Jackson and Gov Maharaj to chat about debugging application compatibility issues (and some of the things Microsoft has done to mitigate typical app compat issues we've run into)."
Enjoy!
What are sub-queues? Subqueues are implicitly created local queues that are logical partitions of a physical queue. Applications can use subqueues to group messages. Subqueues are implicitly created when opened, are deleted when empty, and have no open handles. Messages cannot be sent to a subqueue. Messages can be received from subqueues, moved between the main queue and its subqueue, or moved between a pair of sibling subqueues.
Subqueues do not have their own properties or state, but share the properties and state of their parent queue. For example, a subqueue does not have its own quota, access control list (ACL), or transactional type. Subqueues share the quota of the main queues. Messages in the subqueues consume the quota of the main queue. Subqueues cannot be created under journal and other system queues, or other subqueues. If journaling is enabled, copies of messages that are removed from a subqueue are sent to the journal queue of the main queue.
So why sub-queues? MSMQ-based applications often require messages to be grouped based on some criteria. Previously, the only way to do this was to create several queues and when a message arrived in the main queue, move the message into a specific queue based on some selection criteria.
Here’s the thing: moving messages between physical queues is a resource-intensive process. If you are wanting to build a high performance application, it is best to try to avoid this resource-intensive process. But if you were building an application based on MSMQ 3.0, this was not very feasible. Now, the new sub-queues feature enables you to logically group messages within a single queue without the need of creating another physical queue.
- MSDN Documentation
- WCF Examples
I have posted a new video to the Developer Meet Server Show on Channel 9. This video discusses common MSI Installer Issues you might run into if deploying an application onto Windows Vista or Windows Server 2008. From the description of the video:
"In this video, we chat with Robert Flaming about application compatibility issues around Windows Installer for Windows Vista and Windows Server 2008. Mark Taylor, from our first Application Compatibility video, sits in as well to fire off some important questions (well, questions that are perhaps more educated than I would ask)."
Enjoy!
What is Windows Process Activation Service? Windows Process Activation Service, also referred to as WAS, is a new component in IIS 7.0 that manages application pool configuration and worker processes instead of the WWW process. This enables the same configuration for both HTTP and non-HTTP sites to be used. Thanks to this separation (and in combination with the new modular architecture of IIS 7.0), you can even host non-HTTP sites without the WWW Service even being installed in the first place.
How does Windows Process Activation Service work? Taken directly from the documentation:
“The WAS process model generalizes the IIS 6.0 process model for the HTTP server by removing the dependency on HTTP. This allows WCF services to use both HTTP and non-HTTP protocols, such as Net.TCP, in a hosting environment that supports message-based activation and offers the ability to host a large number of applications on a given machine."
What scenarios does this enable? Since WAS is not specific to HTTP sites, you can use WAS to host non-HTTP sites as well. But what do we mean by “non-HTTP sites?” Well, simply put, WAS can be used to host sites built on technologies like Windows Communication Foundation, for example. If you are using WCF with WAS, are you limited to listening over HTTP? Not at all. In fact, that is the beauty and power of WAS. You can be hosting a WCF service within WAS that is using a netTcpBinding, netMsmqBinding, etc. As an extension to this, since WAS supports both HTTP and non-HTTP sites, this also means that you can be hosting a service that exposes itself over both HTTP and NET.TCP as well.
Well, at least I found it funny. A coworker brought this to my attention today. I thought it was pretty clever and enjoyed it. Then again, I've known for a while how great Windows Server 2008 is :). Here's an excerpt:
Once I was almost famous. For years, my friends and I were on the front lines: we were the Windows Server 2003 servers that powered Microsoft.com, one of the hottest Web sites in the world. Then, early last summer, everything changed. Quietly, without warning, the new kids took over. Windows Server 2008. Yes, I know, the product’s not even done yet. These were Beta 3 servers, for Pete’s sake. Long way from prime time. But there they were, humming away. No problems. All of ‘em on Windows Server 2008. Except me. The last Windows Server 2003 left at Microsoft.com.
Enjoy!
Hello everyone, and welcome back after our winter break hiatus. We have a lot of cool features to cover in the coming weeks that will especially show off the power of Windows Server 2008 as an application server. So, this week we will kick off the new year by taking a short little peek at the new management API coming in IIS7.
What is new in IIS7 Administration? IIS7 provides a comprehensive managed-code API that allows complete manipulation of the XML configuration files and convenience access to server objects. IIS7 includes Microsoft.Web.Administration, which is a new management API for the web server that enables editing configuration through complete manipulation of the XML configuration files and also provides convenience objects to manage the server, its properties and state. The configuration editing aspect of the API provides programmatic access to read and write configuration properties in the IIS configuration file hierarchy and specific configuration files. The object management aspect of this API provides a series of top-level administration objects for direct management of the server (i.e. sites, application pools, worker processes, etc.).
The management classes reside in the Microsoft.Web.Administration namespace. The classes provide a weakly-typed interface to access configuration sections and convenience objects with properties and methods representing attributes of the configuration (like the path of a virtual directory) or actions to take on the object (like recycling an application pool).
Resources
As part of the "Developer Meet Server" show on Channel 9, I have started a new series of videos on the topic of application compatibility for Windows Server 2008. I will be releasing one video interview per week all the way until launch, so make sure to keep an eye open!
in this first video, we discuss a bunch of topics in this video that are very pertinent to the topic of Application Compatibility on Windows Server 2008, from Session 0 Isolation to IIS 7 to Mandatory Integrity Control, among many others (I will give any of you five geek points if you can work in "Session 0 Isolation" or "Mandatory Integrity Control" into your next dinner party conversation!).
So, make sure to go check it out.
In my previous post, I talked about why I personally love C++/CLI as a solution for managed and native interop. With the launch of Visual Studio 2008, and the include of the new marshalling library, there is on part of the equation missing, I believe. On the C# side of the interop equation, you have http://www.pinvoke.net. When I'm wanting to interop with a given Windows API, there is a very (very) good chance that the wrappers have already been posted onto pinvoke.net.
While the marshal_as<> construct of the marshalling library in VC++ 2008 is quite extensible through the use of templates, there is no community site for me to go to in order to retrieve an existing piece of the interop puzzle. That is, until now.
With the help of Kate Gregory, there is now a new website for those C++/CLI users out there: http://www.marshal-as.net. If that link doesn't work for you, give it a day or two as this is a new website and DNS is still propagating for it.
I have already sent Kate a couple of samples that I had done for my own interop work with Visual C++ 2008 (have I mentioned yet how easy my life is now that I'm using C++/CLI in Visual C++ 2008?). You should pop over and check it out. If you have your own samples that you want to submit, feel free to use the contact form (the email icon) at the website and email your sample to the website.
Enjoy!
This is a topic that I've been thinking a lot about lately. And I would really like to get all of your opinions as well (especially if you disagree with me).
This debate came up recently (again) on my trip to Tech Ed Developer in Barcelona. If I am having to write interop code, should I use C# and p/invoke, or should I use C++/CLI? I had some very smart people like Kate Gregory and Daniel Moth to chat with this about. Kate and Daniel are definitely good people to chat with because, honestly, they have completely different opinions on this topic. Kate is on the C++/CLI side of things, especially for serious interop tasks, while Daniel believes that you should keep it in C# no matter how complicated that C# gets. So, what side of the fence do I fall on?
This is a question I've been pondering for a while now. Since I first came in to this Windows Server 2008 Technical Evangelist, I've had to write a lot of interop code. And I personally believe in using the right tool for the job. And while p/invoke is great for smaller interop jobs between native code and managed code, it can "get out of hand" quickly. For instance, to p/invoke into the new Transactional NTFS APIs, I could look at having to create a bunch (several hundred lines of code or many more) of interop structures merely to call DeviceIoControl to get issue a single TxF command. Here's the thing: all those structures are all ready defined on the native side and could be used with ease (as in, a simple "#include" statement) on the C++/CLI side of things. No extra code necessary.
But it's not just the structure definitions that are the problem, it is also the programming paradigm used in the native code you are trying to interop with. When dealing with a simple Windows API function, this may not be a problem at all. Of course, it gets a little scary when dealing with COM interop, but at least there are still the tools built into C# to interop with COM. Where the train really starts to derail is when you start writing interop code for a native library that uses a different paradigm.
For instance, let's look at DeviceIoControl. It's not really one function call, it's a complete API in itself. I've had to get familiar with DeviceIoControl when doing my work with Transactional NTFS. DeviceIoControl uses a much more conversational paradigm than managed developers are perhaps used to. Here's a common "calling session" with DeviceIoControl (minus all the fun exception handling that should be there):
while (true)
{
// Clean-up previously allocated memory
// Allocate memory
// Issue command
if (!DeviceIoControl(...))
{
if (GetLastError() == ERROR_MORE_DATA)
{
// Determine how much more memory we need
continue;
}
}
else
{
// There was enough memory finally
// Pull data out of buffer we issued to DeviceIoControl
break;
}
}
When writing managed code against this DeviceIoControl paradigm, you will write more code that is harder to maintain and debug than you will if you simply used C++/CLI to do the interop. With C++/CLI you can use the API natively exactly like it's meant to be used, and then "expose" the code to the managed world via C++/CLI. When I moved my Transaction NTFS wrapper from C# to C++/CLI, I was able to remove a large chunk of code, and it was much easier to read and understand. Using the right tool for the job will do that for you.
The DeviceIoControl paradigm is just one example though. Another "hang up" when writing interop code in C# is when you need to do some very detailed memory and pointer manipulation. Take this following piece of code that is used within the DeviceIoControl pattern above and is used to get the list of running transactions on a system (assuming the "list" has already been populated):
// Loop through the transaction entries and store them in a list
TXFS_LIST_TRANSACTIONS_ENTRY *txEntry;
txEntry = (TXFS_LIST_TRANSACTIONS_ENTRY *)((char *)txList + sizeof(TXFS_LIST_TRANSACTIONS));
for (DWORD i = 0; i < txList->NumberOfTransactions; i++)
{
TRANSACTION_ENTRY *newEntry = AddTxFEntry(txEntry->TransactionId, txEntry->TransactionState);
// Each transaction is attempted to be loaded with their files ASAP (if any).
LoadLockedFiles(rmDirectory, newEntry);
txEntry++;
}
This code is a PITA to write in C#. Not only do you have to write all the interop structures for TXFS_LIST_TRANSACTIONS_ENTRY, TXFS_LIST_TRANSACTIONS, and TRANSACTION_ENTRY, but you have to do all the pointer fun via the Marshal helper in C#. Sure, you could pop into unsafe code and deal with pointers directly, but I think if you are willing to do that, you should be more than willing to just use C++/CLI. Why would I go through all that, if I can just write the code and expose the results to managed code via C++/CLI? As soon as I switched the wrapper from C# to C++/CLI, my job got a LOT easier. And this is coming from a programmer that is relatively new to the whole C++ world. If I can write in C++/CLI for interop, I honestly believe any committed C# developer can as well.
Let's look at a small snippet from the Transactional NTFS Wrapper:
FileStream^ TransactedFile::Open(System::String ^path, FileMode mode, FileAccess access, FileShare share) {
...
////////////////////////////////////////////////////////////////////////
// We need to marshal our values into native types since we are
// going to call into a native Windows API based on CLR parameters
marshal_context ctx;
const wchar_t *marshalledPath = ctx.marshal_as<const wchar_t *>(path);
HANDLE fileHandle = CreateFileTransacted(marshalledPath,
marshal_as<DWORD>(access),
marshal_as<DWORD>(share),
NULL,
marshal_as<DWORD>(mode),
FILE_ATTRIBUTE_NORMAL,
NULL,
kernelTransactionHandle,
NULL,
NULL);
...
}
This is the actual segment of code that does the main interop piece for me. Is the above that intimidating? A couple of things to note to those C# developers out there. You can think of the "^" as denoting "by reference". Yes, it's a bit more complicated than that, but just think of it that way for now, that's all you need to know. And the "::" operator is your namespace operator. So instead of "System.String", I have "System::String". Once again, a very simple syntactic difference.
The marshal_context object is a new object introduced with Visual C++ 2008 as part of the new marshalling library. By using the marshal_context, the context will take care of memory allocation and de-allocation for the strings we are are interop'ing. Very simple. The CreateFileTransacted API expects the path to be a "const wchar_t *", so I simply marshal our passed System::String as "const wchar_t *" and we're good to go. Since marshal_as<> is template based, it's very easy to extend yourself. And that's what I've done with marshalling System::IO::FileMode/Access/Share as DWORD (which I will show in a future post).
Now, honestly, is that piece of code that scary? If you have questions about it or things that still scare you, please let me know and I will look at writing a future post on the topic.
Back to the debate at hand though: C# versus C++/CLI for interop. I can certainly understand where Daniel is coming from. C# developers can quickly become intimidated when seeing C++/CLI code. It isn't the C# code they know and love. But I'm not sure he gives C# developers enough credit. It's an important step for developers to realize that, syntactically, C++/CLI and C# are not that different. If you are familiar with reference types in C#, you are probably more familiar with pointers than you realize. There are some "gotchas" around topics like pinned pointers, but they are concepts you need to know in C# as well if writing interop code there, so they aren't that big of a deal in the end. I'm not saying to not use P/Invoke and C# though. I'm simply saying to use the right tool for the job. If it is a very simple Windows API you are writing interop code for, C# and P/Invoke is probably "good enough". For more complicated interop jobs though (as in with most of the new enhancements in Vista and Windows Server 2008), why not use C++/CLI since it will make your life easier one you get over the small learning curve?
Did I have this same opinion before Visual Studio 2008? Yes, and no. Yes, C++/CLI code was still built for interop, but I honestly believe that the introduction of the extensible marshal_as<> construct (combined with other technologies like STL CLR) make interop in C++/CLI even more powerful and easier to use than before. For instance, marshalling strings was not fun to do before Visual Studio 2008 (especially for a developer not extremely aware of the different ways to use strings in native code). However, out of the box, the marshal_as<> construct provides a lot of different ways to work with and to interop with strings. And in all of these ways, you don't have to worry about allocating or de-allocating memory at all (ah, the same joys I get when working in a garbage collected world). And in the case that you are interacting with C++ libraries that are possibly STL-based, STL CLR provides you with a library that you simply don't get in C# (interop'ing with C-based Windows APIs are one thing, interop'ing with proper C++ libraries are a completely different beast when using C# for the interop code).
If you are a C# developer that writes _any_ interop code, you owe it to yourself to learn C++/CLI. Trust me, it will make your life much easier, and it's not that hard to learn. And being scared of pointers is no excuse. If you are comfortable with reference types in C#, you are probably more familiar with the concept of pointers than you realize. Plus, with STL and Boost (even more so with the upcoming TR1 work), there really is no need to have a pointer anywhere in your modern C++ program (ah, the sweetness that is the shared_ptr).
So with the launch of Visual Studio 2008, I believe that the "right tool" for the "interop job" is C++/CLI for anything that is beyond trivial. Constructs and libraries like marshal_as<> and STL CLR only drive this point home more. You can feel free to continue to write thousands of lines of managed-code-copying-already-defined-in-header-files simply to p/invoke into an existing Windows API, but me? I will be using Visual C++ 2008 and enjoying every minute of it since I don't have to do any re-invention of the wheel.
Mandatory Integrity Control (MIC) is a cool new security feature built in to Windows Vista and Windows Server 2008. It adds another "layer" of security to Windows resources (files, processes, etc.) over the usual DACL (Discretionary Access Control Lists) that we have in Windows XP and Windows Server 2003.
Essentially, Mandatory Integrity Control adds an "Integrity Level" to resources present in the Windows operating system. There are four possible integrity levels. They are (from most privileged to least privileged): System IL, High IL, Medium IL, and Low IL. System Services run at System IL, Administrative Processes run at High IL, and all resources in Windows with an explicitly set integrity level exist at Medium IL by default. When one resource wants access to another resource, the first resource's integrity level must be greater than or equal to the integrity level of the requested resource. This integrity level check takes place before we even check the DACLs on each resource.
Processes, for instance, can access files that have an integrity level lower than or equal to their own integrity level. So let's say I have Notepad running under my own local account (not an administrative account). By default, Notepad.exe is launched with an integrity level of Medium. As long as I am trying to write to a file that has an integrity level of Medium or below, then the operation will success just fine.
However, if I have a file that is sitting there with an integrity level of High, the write operation from Notepad will fail because Notepad doesn't have the proper integrity rights to access and to write to that resource.
Let's go ahead and take a look at this in action (you can work through this "demo" if you are currently running Windows Vista or Windows Server 2008).
Demo
You _must_ be running Vista and Windows Server 2008 for this demo to work
1) Launch Notepad
2) Enter some text and save the file as “test.txt” on your desktop. Now we have a text file with the default Medium IL.
3) Launch a command prompt as Administrator (from the shortcut, right click and choose “Run As Administrator”)
4) Navigate to your desktop (“cd C:\Users\USER_NAME\Desktop” in the command line for a default Vista installation).
5) Issue this command to set the created file’s integrity level to a High IL: “icacls test.txt /setintegritylevel H”. Now that the file has a high integrity level a default notepad process won’t be able to save the file.
6) Launch Notepad again (make sure it isn’t launched as Administrator since Administrator permissions will make it have an integrity level of High, voiding this experiment).
7) Open test.txt from your desktop
8) Change the file and try to save it. Notepad will fail while trying to save (Notepad gives a “user-friendly” error, but the underlying error is actually “Access Is Denies”).
There you have it, Mandatory Integrity Control in action! However, that's not the end to the story!
Did You Know? Internet Explorer “Protected Mode” actually uses Mandatory Integrity Levels under the hood to achieve its goals. Since IE Protected Mode runs with a low integrity level, and all files on the file system (and running processes) are a medium integrity level by default, an attempt to write to those files or processes fails.
