A Brave New World:
UNIX Developers in an NT Land

by anonymous
<[email protected]>

Editor's note: The author believes this article could jeopardize his position with his employer. Therefore, I am allowing it to be published anonymously. Communicate with him via the email address below.

Take a bunch of developers used to the UNIX programming environment, move some of them over to NT, and you end up with less productive programmers who grumble a lot. Here are some of the problems we faced and what we were able to do about them and, in some cases, what we weren't able to do about them. No claim is made that our solutions or workarounds are universally the best ones or even the best one for any developers you might be supporting who are making the same crossing into a new world.

Shells and Stuff

MS-DOS's COMMAND.COM is reviled by many, and CMD.EXE (the default NT command shell) isn't a whole lot improved. This is too bad because there have been many shareware and freeware replacement command shells for COMMAND.COM that have been available for years (my favorite from a past life was the 4DOS/4NT/4OS2 shells from JP Software), and it would have been nice if CMD.EXE would have learned yet more from them. That's not to say there aren't a few improvements: for example, CMD.EXE windows support using the mouse to initiate marking text for cut and paste (although you have to use ENTER to end the marking, and you can mark only rectangles), and TAB does file completion, provided you tweak the right magic registry settings.

(Sure, uh huh, NT is much easier to administer than UNIX; after all UNIX has those horrible, obscure text configuration files, but NT has nice GUIs and, oh, by the way, equally obscure registry settings. Moral: obscurity isn't inherently a UNIX vs. NT thing.)

Some of us use CMD.EXE anyway, but others use a freely distributable port of tcsh. Although there are supported commercial packages like the MKS toolkit that include various shells, UNIX utilities, etc., so far we've opted to go with freely distributable ports of various utilities. Those of you who remember ports of various UNIX tools to MS-DOS (with considerable code rewriting necessary in the port effort and often with much functionality lost) shouldn't let those memories unfairly prejudice you against the ports that are now available. Porting to Win32 at the very least allows not having to mangle 32-bit code back into 16-bit code, and although the NT POSIX subsystem is incomplete, it's adequate for some utilities, and Win32 console mode is adequate for others. Even a fairly good freely distributable port of emacs19 is available, as are good ports of vi and derivatives.

Having a nice directory full of such gathered stuff on a server and exporting it to everybody reduces some of the grumbling. And that brings us to the next topic.

File Sharing

Fundamentally, we saw two choices between what protocols were going to flow over the network: NFS, which we all know and just love, or SMB, which stands for Server Message Block and is the foundation of Microsoft LAN Manager and subsequent native Windows and NT file sharing for both peer/peer and client/server. If we went primarily with NFS on the network, we would have to buy NFS clients for all NT systems and possibly NT NFS servers for at least some of the NT systems. The pro was that then everybody could talk to everybody; both UNIX and NT systems could act as servers and as clients as long as we were willing to spend the money. The cons were the money and that we had heard claims of instability with adding NFS to NT, claims we weren't interested in confirming or denying ourselves.

We decided to go with SMB. Both commercial and freely distributable SMB servers exist for UNIX; we opted to try out Samba, which falls into the latter category, to simplify administration­anybody who wanted to try it out on a UNIX system could; we didn't have to count heads to see how many licenses we needed to buy. Samba enables the UNIX system to act as a fileserver (and print server, too, although we are not using that functionality); from an NT system, accessing a share (the term "share" is roughly equivalent to an exported filesystem specified in /etc/exports for NFS) on Samba server is just like accessing a share on an NT system.

The con with going with Samba is that there's no similarly transparent way for an NT system to serve files to a UNIX system. Samba supplies smbclient, whose UI is much like the standard UNIX FTP client. So on a UNIX system you can get and put files to an NT fileserver, but this is a bit awkward.

In any case, in practice, this inability to access NT shares transparently from a UNIX system has not been a major problem for our development workflow. For rarely accessed files, people will use smbclient; for more commonly accessed files, we can have the NT system serve the files via HTTP. One major reason we haven't stressed too much about transferring files back and forth is that our revision control system handles that without needing to have shared network filesystems.

Source Code Revision Control

Source code revision control systems are nearly as touchy an issue as favorite programming editors. They are actually worse in that you need to impose the same system on entire groups of developers, whereas individuals within that group can use their own favorite editors in semipeaceful coexistence with only occasional firefights. We had an in-house system that evolved over years with which developers weren't entirely happy, but at least they were used to it. But adapting it to work with NT seemed to be an intractable problem not worth butting our heads up against. We solicited opinions, looked for Web pages, read vendor glossies, even had some small, hungry companies come give us presentations. Finally, we opted to adopt Perforce. Their Web site will provide all the glowing points you want, but we particularly liked the number of supported platforms for both client and server, efficient use of network bandwidth across WANs (single TCP connection per client invocation), atomic changes, ease of writing scripts to add functionality, and the lack of requiring that you structure your development cycles and workflow the way they think you should. So far, we have no major regrets after months of usage.

A little gotcha about NT that we noticed only in the context of the source code revision control system is the annoying case insensitive but case-preserving semantics of NT filesystems. If developer #1 checks in \lib\foo.c from an NT system and developer #2 checks in \LIB\bar.c from another NT system, developer #3 on an NT system, who gets top of trunk, will see both files in the same directory, with the exact case of that directory's name being either lib, LIB, or possibly something else if developer #3 already had the directory created. But a developer on a UNIX system ends up with two files in two different directories and is left to wonder why he can't perform a full build any more. Perforce suggests several workarounds for this problem, one of which works fine for us, but it's nevertheless an annoyance.

Working Remotely

We have a fair amount of telecommuting. Most people work only occasionally from their homes, but several people live hundreds of miles away and are only in the office a few times a year. Being able to access resources across a dial-up session is therefore important. UNIX provides flexibility in how to access resources remotely: you can run everything on your local home system and go across the dial-up for remote filesystem access, or you can remotely login to a system at work (rlogin/telnet) and run text mode applications and tools or even X applications and tools, if you have the patience. NT supports the former just fine (SMB on TCP/IP on PPP is no problem), but doesn't support the latter out of the box. We knew there existed various commercial packages that support remote access for Windows by duplicating the entire desktop that appears on the graphics monitor across the dial-up session to be displayed on the home system and that over the years their speeds have even come to be about as tolerable as, perhaps even better than, running an X app across a similarly low bandwidth network connection.

We never got around to checking if such packages work on NT, though, because somebody stumbled across commercial software from Ataman Software that served our needs nicely­a Telnet daemon that runs on NT and allows you to Telnet into it. This is not to be mistaken for the beta Telnet daemon that is available with one of the NT resource toolkits that Microsoft sells in book+CD-ROM form, which is horribly unstable. The Ataman Telnet daemon is pretty stable, and establishes a session running your favorite shell, within which you can run console mode programs. You can't run IDEs or GUI debuggers, but at least you can fire off compiles using a command line compiler front end. Even when at the office, the Telnet daemon is quite handy; you don't have to switch keyboards and mice and possibly even have to turn around and move your chair to use another NT system. Because NT supplies a Telnet client, remote login in all combinations works fine.

Conclusion

Developing on NT isn't nearly as bad as developing for DOS or Windows 3.x is. No horrible hacks like using the keyboard controller to forcibly reset the CPU between protected and "real" mode, no near vs. far pointers and plethora of "memory" models, no A20 gate, expanded, extended, and "high" memory to worry about in your applications; that stuff is gone. Networking and file sharing don't have to be bolted on after the fact any more. With a little bit of work in setting up the software environment, NT can become a reasonably tolerable environment for software development, even for UNIX-biased developers ­ a backhanded compliment, to be sure, but a compliment nevertheless.

[Author's note: A search engine like AltaVista should suffice to help you find vendor Web sites, distribution sites for freely distributable software, etc.]

[Disclaimer: Mentions of products should not be taken as endorsements. The author has no commercial relationships with vendors of add-on products mentioned other than as a paying customer in some cases.]