The "U" Word : Microsoft Solutions for Unix

NetBSD adds support for SFU/Interix to its Packages tools

jdzions — Sun, 14 Mar 2004 21:36:00 GMT

See this OSNews.com report. The cool thing - over time, more and more packages can be easily downloaded, built and installed for SFU with one simple command.

Migrating to Linux is far more expensive than expected

jdzions — Wed, 18 Feb 2004 23:42:00 GMT

Just read an article about the experience the City of Munich is having in migrating from Windows to Linux. Apparently, the migration project has run into some serious snags and cost overruns in the areas of secuity, compatibility, and stability. They're also getting hit harder than they expected for training costs.

The city council is demanding an investigation, since they were promised “cheaper”. Apparently some people have forgotten that even during the final project bid process the Windows solution was known to be less costly, since Microsoft apparently dropped trou' on pricing.

My guess (based on personal experience with Unix, Linux, Windows, and watching dozens of customers try to migrate in both directions) is that, when the project is completed, the City of Munich will discover that the project cost more money with Linux than it would have with Windows even at the original bid before discounting. The cost of becoming ones own operating system development and application testing shop is huge and on-going, to the extent that there isn't enough calendar time to amortize and recover the expense.

(And I so enjoyed reading the comments attached to the article, too. Everything from Linux fanboy flamage to “Microsoft is still evil” flamage to “The playing field still isn't level” whining to... )

"Essentials of Windows for UNIX developers" on-line course goes live!

jdzions — Sat, 14 Feb 2004 00:11:00 GMT

When discussing with CIOs and IT directors the idea of adding Windows to the set of platforms for which they develop custom line-of-business apps, one of the most common questions I hear is this: “I've got a team of 50 (or 150, or...) UNIX developers who've been doing that for ten years, or more. How can I get them up to speed on building apps for Windows?“ A serious problem, since developers are not fungible resources; even if you could replace a UNIX-skilled dev with an equivalent Windows-skilled dev, that new person wouldn't have the unique knowledge of the application and the business that is required to effectively build the right apps in the right way.

I've been working on answering that question for the last 8 months. Microsoft courseware has traditionally accomplished two tasks: how do you turn a total neophyte into an effective developer, and how do you introduce the latest and greatest features or subtleties to a person who is already an expert in the previous or current version of our products. We've had nothing that addressed the need to take an expert in the same technology on a different platform and bring them up to speed on the appropriate Microsoft products as rapidly and efficiently as possible. That is another facet of the basic question posed.

The newest part of Microsoft's answer is an on-line computer-based training (CBT) course, Learn the Essentials of Windows for UNIX Developers. It's not heavy-weight; a motivated person could plow through it in far less than a day. But it's crammed full of pointers to content on MSDN, Microsoft.com, and other web sites; lots of references to books, articles, etc. It talks about how developing for Windows is different from developing for UNIX, and why those differences exist. History and philosophy of OS architecture as it applies to the differences between UNIX and Windows.

Everything the typical I'll-learn-it-myself UNIX dev needs to start getting his brain wrapped around modern Windows development.

This course is a just-for-devs version of the admin-focused CBT course, Learn the Essentials of Windows for UNIX Administrators.

Check'em out. Find errors? Let me know. Want to quibble about what they say? I'm all ears. Know a friend with lots of UNIX skills who wants to expand her technical horizons? Pass it on.

Four new UNIX Solution guides released

jdzions — Sat, 07 Feb 2004 01:24:00 GMT

Last Friday my team released the last of four guides planned to release by the end of 2003. (Hey, only a one-month slip isn't bad!) That brings the total number of guides in the area of UNIX migration and interop to 8. See the set of links at the left side of the screen to get there.

My manager wrote an internal announcement on this stuff, and he promised me there'd be a press release. So I searched PressPass - nothing there yet. Sigh. It'd be nice to be able to point my Mom at it and say “See? This is what I sweat blood over.”

Microsoft releases Solution Guide for integrating Unix systems with Windows for Authentication and Authorization

jdzions — Sat, 07 Feb 2004 01:02:00 GMT

As promised two weeks back, we finally got this out the door last week. Sorry I'm so late in letting everyone know; it's been a week of getting myself dug out from a sudden, unexpected trip to Boston and then to New York for LinuxWorld.

Solution Guide for Windows Security and Directory Services for UNIX
Using Active Directory and Kerberos for authentication and identity store in a heterogeneous UNIX and Windows IT environment.

Why is there no X Server in Services For Unix?

jdzions — Mon, 19 Jan 2004 07:19:00 GMT

As I've been trolling blogspace for posts on the new Services For Unix, I've noticed one question coming up more than any other: “How do I turn on the X Server in this thing?”

There is no X Server in Services For Unix.

“But... How can it be Unix if it doesn't have X?” I hear you cry. (If you haven't cried it yet, go ahead - I'll wait until you're done crying. :-)

I've been at Microsoft for more than four years, now, and I've been intimately involved with the SFU product for that entire time. I know that the SFU team has considered the question “Do we bundle an X Server” every six months, like clockwork, during that entire time. Each time, we reluctantly came to the conclusion that the answer should be “no”.

Let me talk through the analysis that would have applied up until the decision was made to release SFU for free. (As you'll see, that decision simplifies the analysis quite a bit without changing the answer.) There's nothing earth-shattering here; with a year of b-school or five years experience as a professional software developer at a company that makes software as a product, you could predict everything I'm about to “reveal“.

Suppose the SFU team had decided to bundle an X server. The next question to be resolved is “which one”. That devolves into two decisions: Make vs. Buy, and in the latter case, ISV vs. Open Source.

If Microsoft were to license a commercial X Server, it would have to pay a licensing fee to the owner of the software; that's serious money, and they'd have to raise the price of SFU. Remember that SFU cost $99 for a single copy; volume discounts and educational discounts were not insignificant. Commercial X Servers cost a significant fraction of that price; heck, Hummingbird Exceed retails for over $200. The price increase would be large. Moreover, we knew that many of our customers already had licensed a commercial X Server for other purposes; they didn't want or need another one, and would be annoyed to pay for it.

Microsoft could ship a freeware/OSS X server (i.e. XFree86). By putting it in the product, though, the company would be committing to support it, and that's an expensive can of worms. Microsoft wouldn't be adding value to Xfree86 by putting it in SFU; getting XFree86 from elsewhere is precisely as useful to our customers. Sure, the SFU team does bundle gcc, but that particular technology is demanded by many customers and it had to be ported to run under SFU anyway; that is, Microsoft added value to the gcc we built over the one that was availabile prior to our participation. Since we did the port of gcc, we understood the technology well enough to support it. (By the way, the source code for the gcc in the SFU package is, and has always been, available from Microsoft. Details are in the SFU package.)

Microsoft could build one of its own. That's really expensive, and saddles the company with support expenses, and competes with companies that have been good partners to Microsoft in the past. Yes, there are times Microsoft chooses to do that. You can imagine the internal analysis required to support that kind of decision. An X server is not a strategic product for Microsoft, and the company would be adding no value to the product (vs. any other X implementation) by making its own, so piddlin' in someone else's tea would be completely unjustified by any rationale analysis.

With SFU 3.5 being free, the economic choices become even more stark. We could put XFree86 in the package, but people would expect Microsoft to support it (and rightfully so); Microsoft wouldn't be adding any value that way, so there's just no reason to do it.

So what are the alternatives? I've used these three:

XFree86.
Hummingbird Exceed. (Best pricing I've seen is from Interop Systems; they repackage Exceed so that it doesn't try to install other networking stuff SFU already has.) Probably the best OpenGL support and performance of any X Server. Certainly the market leader in terms of installed base.
X-Win32 from Starnet. Lower-cost, good perf, good stability.

There are probably a dozen others. I stick with exceed, but that's because I need to play with Unix OpenGL code from time to time. Your mileage will vary. Try a bunch; find one you like that delivers the best value. Only you can determine what “best value“ means.

Note: The preceding information is given as-is with no warranty.

Turning a Unix App into a Web Service using SFU and .NET - Part 1

jdzions — Sun, 18 Jan 2004 06:11:00 GMT

For the last couple of years, the SFU and MSUM teams have shown a demo that takes a Unix application, ports it to Windows using Services For Unix, then turns the app into a COM server and into a Web Service. I've been trying to find the time to write the thing up through formal communications channels at Microsoft for at least the last two years.

Some people have gotten tired of waiting. In particular, pleloup most recently asked the question.

Let me start by explaining roughly how this works. Later posts will go into the (slightly) gory details.

The most important thing to remember about building apps using the Interix environment in Services For Unix: you cannot mix Unix and Win32 calls in a single process. If the app makes Interix calls (fork, exec, all those other nasty Unix-isms that are hard to emulate through Win32, etc.) then it can't use Win32 calls. This is an architectural design limitation of the Windows “user-mode environment subsystem” model which Win32 and Interix use.

If you think about it for a second, the limit makes a lot of sense. For example, no Win32 API has semantics defined for the fork() operation. Behavior is documented for CreateProcess(); which things are inherited by the new process, which aren't. But fork() is quite different from CreateProcess() and the defined semantics for the latter are insufficient to describe the former. Or try mixing Unix signals with Win32 structured exception handling. When you consider all the tiny little details of the programming models of the two worlds, they're just not compatible. The Windows “subsystem” model puts a high wall between the two API families.

Given all that, there are two obvious ways to expose a Unix app as a web service on Windows. You could port an entire open-source Unix-based web services infrastructure to Windows via SFU; start with apache (already done for you), add a couple dozen libraries and tools, hire a couple consultants, and you can probably make it work. Or, build the web service using VS.NET and “leverage” the functionality of the separate Unix application process to deliver the goods.

That's what we did. We built a small set of C# classes that allow a .NET app to run any Interix application and capture its output (stdout and strerr). Using that, our demo contains a web service which exposes a couple of relevant methods on a target Unix app (which computes tide tables). The implementation of those methods uses the helper classes to invoke the app and capture the output, which the rest of the .NET Framework takes care of translating into XML and returning to the caller.

It's that easy. Of course, the complexity comes into play when you think more about how to communicate from the .NET Web Server to the underlying Unix app. The demo just uses command-line invocation, which is easy but not terribly efficient. If the Unix app exposes an RPC server (e.g. using ONC RPC), then the web method implementation would just make an RPC call to the Unix server. You could build some unsafe C# code that maps a file into memory, and build the Unix app to map the same file; now you have shared memory to move lots of data in the blink of an eye. And so on.

The COM version of the demo follows the same pattern: build a COM server in Win32, but the implementation of a COM method uses a helper function to invoke a Unix app, capture the output, and reformat for consumption. The code is longer, since COM doesn't make this as easy as the .NET Framework, but it gets the job done. One of the demos is an excel spreadsheet with a VBA macro that creates an instance of the demo COM object and stuffs the textual data into a table which it then uses to build a graph. The X11 version of the Unix code has about 4000 lines of code to graph the tide data; replace that with 17 lines of VBA macro and 250 lines of C++ COM code. Voila.

I'll post some code early next week.

Integrating Unix and Windows systems - authentication and authorization via Kerberos and LDAP

jdzions — Sat, 17 Jan 2004 09:53:00 GMT

While cruising the blogosphere to see who was saying what about the newly-released Services For Unix 3.5, I tripped across this post by Joseph Scott. It looks like one of his primary interests is setting up his FreeBSD system to pull Unix directory information out of AD.

This is good news to me, since my team has been really hard at work building a “patterns & practices” guide that tells you, step by step, exactly how to configure a Unix or Linux system to:

authenticate via Windows Kerberos (single sign-on for real!) using MIT 1.3.1 or Heimdal Kerberos and a PAM module
use nss_ldap and pam_ldap to get authorization data (uid/gid and other user and group information) from AD whose schema has been extended either with the SFU 3.0/3.5 schema or with rfc2307.

It also shows you exactly what you have to do on your DCs to make all this work right.

We burned a lot of midnight oil over the last two weeks to get the guide whipped into shape. We're gonna ship it by the end of the month, and it should be available for free download from technet before Feb 1.

It's not perfect, but we don't want to make people wait for it now that SFU 3.5 is out. This may be another case of “Microsoft gets it right after release”, but I'd rather folks see it sooner. If we made the wrong call, I hope people tell me. Heck, if we made the right call, I hope they tell me.

Services For Unix 3.5 ships - and it's Free!

jdzions — Thu, 15 Jan 2004 18:13:00 GMT

I am totally stoked about seeing SFU 3.5 ship. I'm even more stoked about the price - zero. Yep, that's right, Microsoft is giving away "Services For Unix". Free as in "free beer".

http://www.microsoft.com/windows/sfu has all the product stuff, but that's only half the fun. Take a gander at SlashDot; this thread is about the least negative stuff I've ever seen about Microsoft posted there. Given that the /. gang tends to think that Microsoft is a bunch of... well... read it yourself.

As a technogeek, I think the coolest thing about SFU 3.5 is the pthreads support. That feature was #1 with a bullet on the list of “stuff SFU 3.0 didn't have but needed”, and getting it into the product is going enable a whole mess of really cool stuff down the road a bit. And, yes, there is a “down the road a bit” for SFU; this zero-cost-of-acquisition release is not the end of the line.

As someone who has had business conversations with customers who wanted to use the stuff, the “free beer” aspect of the release is kinda cool. There's a small amount of “pucker factor”; the Microsoft sales force might be a little harder to motivate now that there's no revenue to their pocket, but let's face it - with a retail cost of $99 in no volume, they weren't excited about selling 3.0. Now that they can give it away, perhaps they'll be less reluctant to tell their accounts it exists.

And that's probably the best thing about releasing the product this way. Services For Unix has been Microsoft's “best kept secret” for years; too many of our customers have no idea we make this, and I've seen MS sales guys beaten up by their accounts for not telling them about it.

Dang, I'm excited. And I don't have to keep this a secret anymore.