<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">

<html>

<head>
<title>Opinions</title>
<meta name="GENERATOR" content="Microsoft FrontPage 1.1">
<meta name="FORMATTER" content="Microsoft FrontPage 2.0">
</head>

<body stylesrc="logo.htm" bgcolor="#FFFFFF">

<p align="center"><b><u>Regarding your general porting strategy:</u></b>
</p>

<p><u>From: hamilton@BIX.com (hamilton on BIX); on:
comp.os.ms-windows.programmer.win32; Date: 22 May 95</u> </p>

<p><cite>mansionj@gstldn9.merrill (James Mansion LADS LDN X4923)
writes:</cite> </p>

<p><cite>&gt;Arguably, Consensys and Datafocus are doing it
right.</cite> [Using a UNIX style library that are maps to NT
native calls] </p>

<p><cite>I think you meant: &quot;Consensy and Datafocus
www.datafocus.com NuTCRACKER argue they're doing it right.&quot;
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 &quot;market&quot; 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 &quot;fit&quot; 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
&quot;kernel&quot; process. Everyone except those involved can
see what's going on: </cite></p>

<p><cite>&quot;Doctor, Doctor, it hurts when I do this!&quot;</cite>
</p>

<p><cite>&quot;Don't do that.&quot;</cite> </p>

<p><cite>&quot;But I've really get this working but it hurts when
I do this.&quot;</cite> </p>

<p><cite>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.</cite> </p>

<p><cite>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,</cite> </p>

<p><cite>Doug Hamilton KD1UJ hamilton@bix.com Ph 508-440-8307 FAX
508-440-8308</cite> </p>

<p><cite>Hamilton Laboratories, 21 Shadow Oak Drive, Sudbury, MA
01776-3165, USA</cite> </p>

<p align="center"><b><u>Regarding Shell Usage:</u></b> </p>

<p><u>From: feoh@kropotkin.gnu.ai.mit.edu (Chris Patti); on:
comp.os.ms-windows.programmer.win32; Date: 24 May 95</u> </p>

<p><cite>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 :)</cite> </p>

<p><cite>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.</cite> </p>

<p>[4DOS, and the similiar Command/32 V1.0 are available at The <a
href="http://simtel.coast.net" target="_top">SimTel archives</a>
-Ed] </p>
</body>
</html>