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.
Okay, I have a question - as a UNIX developer who does Windows (and WinCE) stuff too.
I originally posted this over at Raymond Chen's blog, but it turns out he doesn't know the answer, and some helpful soul pointed me here, which seems massively more appropriate.
Anyway, on with the question:
All of us good boys and girls who did our homework have known for years that NT's POSIX subsystem (and by association Interix/SFU) support fork().
The Win32 API (as far as I can tell by RTFMing, Googling, newsgrouping, and generally given up trying some time ago) doesn't contain any equivalent - not even a closely guarded one. If I'm wrong, stop me now :)
Assuming I'm on-base up until now, the question is this: POSIX/Interix/SFU all need to get some kind of help from the kernel at some point along the way in order to actually perform the fork. After all, they're subsystems (or a subsystem, depending on how you look at it), not kernel-mode drivers, so they don't have much more access to the MM than I do in my Win32 process. By what mechanism do they get this "help" -- and how POSIX-specific is the help that they get? Specifically, would it be at all possible to utilize this support code - assuming it exists - from within the Win32 subsystem in order to achieve the same thing?
[Unsuprisingly enough, the fact that POSIX apps run in a different subsystem means they can end up being really quite dull -- no "best of both worlds" for developers there]
So, if you know the answer to this, fantastic. If you don't...then apologies for blogspam :)