You may like something by Mark Minasi. He's very much an NT guy, not from a *nix background, but he does know a little about *nix, and, more importantly, he tends to explain things at the conceptual level, rather than just show you pretty pictures of windows and tell you what to click, like so many Windows-related books are wont to do. I perused the first parts of his Mastering Windows 2000 Server a couple of years ago and found it engaging and informative.

However, I can tell you just as a general rule that, moving from *nix to Windows, forgetting most of what you know is a good starting point. Even things that are similar tend to be *deceptively* similar, on the surface, with major conceptual differences lurking beneath the veneer. NT is not quite as out-there different as VMS, but it's most assuredly not Unix.

Notably, NT-based versions of Windows are considerably less Unix-like than Windows 9x, conceptually. Sure, NT has memory protection and file ownership and stuff, features that Unix has and Windows 9x lacks, but these are just features, not paradigmatic issues.

The most completely *alien* stuff in Windows (from a *nix-background perspective) is the networking stuff. Everything you know about networking, just check it at the door. Yes, Windows now uses TCP/IP at the network and transport layer, but the similarities end there. Even very common networking terms like "host", "client", and especially "domain" don't necessarily mean quite what you think they mean, and the differences in terminology are just the tip of the iceberg.

Windows 9x lacks memory protection? I never knew that.

Windows 9x lacks memory protection? I never knew that.

Yes. Aside from NT and the unices, most consumer-grade operating systems lack memory protection, especially most of the ones that were available in the twentieth century. Windows 9x does at least have pre-emptive multitasking; Windows 3.x and all MacOS versions up through 9 have neither. Mac OS X and all versions of NT have both, as do the free unices.

Of course, there's memory protection and then there's memory protection. I suspect that in a few years people will look back at most current systems and say, "They didn't have user-mode drivers or partition the memory for each process into separate code and data areas? I never knew that."

Well, if you're asking in the context of Perl, I suggest starting with Win32, perlwin32 and perlport.

If you have to spend any substantial amount of time on the Windows platform, you may find http://unxutils.sourceforge.net to be a welcome relief.

Personally I prefer the cygwin toolset as its more complete.

---
$world=~s/war/peace/g

To the best of my knowledge Windows has a vastly more complicated security model (token based security) than Unix . It has no /etc/passwd, stat returns (mostly) useful info, getpwuid() is a stricly unix concept that is meaningless in a win32 context. The equivelent of a group writable file is a file with access permissions deriving from a usergroup. Objects in Win32 can have user level permissions or group level permissions, with fine grained tuning, ie, you can say group X has read, write and execute, group Y has read, group Z has read,write etc. Similarly with users. To the best of my knowledge there is no sticky bit.

I suggest you find a book on Windows administration in general. They are usually written for a low denominator, so all that will happen is that you wont have to read all of the explanations of concepts you are familiar with.

Actually a while back I discovered one of the flaws of the Win32 security model. Its _too_ damn powerful. In order to make it powerful it has to be complex, and by making it complex its really hard to do right, which means that in the end people end up not bothering. Security models should be simply enough that any programmer can be briefed on how to use the model effectively with minimal training. Requiring people to have indepth understanding of a complicated security model just means that people will write insecure code, either because they didnt understand how to secure it properly in the first place or because they didnt bother out of frustration.

This is a problem with ACL systems in general. They are extremely flexible and expressive, but require a level of stamina and determination to harness that few except the dysfunctionally obsessive will manage.

(The Unix permission model OTOH is so simplistic that only the most trivial arrangments are expressible. All things considered, I still prefer Unix permissions because at least they make the common, simple things a no-brainer; that ACLs make the hard things possible doesn’t mean these aren’t still an absolutely massive pain. Someday we’ll figure out long-term tenable approaches to security…)

Makeshifts last the longest.

A compromise for the UNIX world might be to allow groups to belong to other groups.

-- Argel