Regarding your general porting strategy:
From: hamilton@BIX.com (hamilton on BIX); on: comp.os.ms-windows.programmer.win32; Date: 22 May 95
email@example.com (James Mansion LADS LDN X4923) writes:
>Arguably, Consensys and Datafocus are doing it right. [Using a UNIX style library that are maps to NT native calls]
I think you meant: "Consensy and Datafocus www.datafocus.com NuTCRACKER argue they're doing it right." The question is how many others agree. While there may be certain cases where the porting library approach makes sense (e.g., for in-house developers with a captive "market" and pressure from management to absolutely minimize the porting effort and source changes), I can't find any reason to recommend this to anyone working in a more competitive environment. I'm fully satisfied that you can invariably get a better product with a native port. Your performance will be better, your functionality will be better and your "fit" with NT will be better. I've had several occasions to help a number of vendors begin their ports from UNIX to NT at the Microsoft porting lab (at Microsoft's request) and at the vendors' locations. Invariably, the best indicator of their early success has been the choice of a native vs. a porting library approach. Folks choosing to use a porting library invariably get totally balled up learning to deal with the ideosyncracies of the porting library. At the end of should have been an intensive week-long learning experience, they still know next to nothing about Win32. Instead, they've flittered the time away trying to do things that should have been simple, like using the debugger: with one of these packages, for example, you try stepping into main() and instead of just stopping at the first executable statement, you're off and running because the library's startup routines have fired off God knows how many threads to handshake with their "kernel" process. Everyone except those involved can see what's going on:
"Doctor, Doctor, it hurts when I do this!"
"Don't do that."
"But I've really get this working but it hurts when I do this."
I can't help but suspect that the reason so many seemingly intelligent, flexible developers might get sucked in to these porting library approaches is because they don't have enough confidence in themselves to learn a new API. Believe me, it can be done. People dumber than fenceposts have done it and you can, too. And as you learn Win32 and as you begin to consider the particulars of your own porting problem, most likely you'll find solutions popping right out at you as ways to get your native port done quickly.
If you think you need to be competitive, you will have to do a native port. Period. If you don't think you need to be competitive or if you think it's going to be all that much faster with a porting library, you are probably wrong. Regards,
Doug Hamilton KD1UJ firstname.lastname@example.org Ph 508-440-8307 FAX 508-440-8308
Hamilton Laboratories, 21 Shadow Oak Drive, Sudbury, MA 01776-3165, USA
Regarding Shell Usage:
From: email@example.com (Chris Patti); on: comp.os.ms-windows.programmer.win32; Date: 24 May 95
Foisting a UNIX shell on NT is IMNSHO the wrong thing for most people's needs. Shrouding yourself in an ever-so-thin veil of UNIX will only make you that much more keenly aware of the fact that you're NOT using UNIX to begin with :)
I would strongly suggest that you at least take a look at 4DOS/NT. It provides just about all of the functionality of a UNIX shell (at least all of it that makes sense under NT.) and a MUCH comfier environment that's tailored to the environment you're in as opposed to the one you'd like to be in.
[4DOS, and the similiar Command/32 V1.0 are available at The SimTel archives -Ed]