gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] tla1.2 on cygwin


From: Aaron Bentley
Subject: Re: [Gnu-arch-users] tla1.2 on cygwin
Date: Tue, 02 Mar 2004 01:33:32 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

Tom Lord wrote:

   > From: Aaron Bentley <address@hidden>

   > There are several approaches to Windows compatibility at the moment:

   > - Lode Leroy's cygwin,
   > - Johannes Berg's native Win32,
> - Compiling on Windows Services for Unix. > It's a question of what aproach is optimal.
Is it?  It seems to me that they involve different and unordered
trade-offs.
I meant "the question is whether Leroy's approach is worth maintaining, not whether Windows compatibility is worth maintaining."

The tradeoffs are
Leroy: requires Cygwin.
Berg: requires NTFS
SFU: requires SFU & NTFS
(All require Windows NT or descendant)

("It seems to me" doesn't count for much at all in this
context since it isn't much of an exaggeration to say, of my knowledge
of Windows, "Didn't that evolve out of DOS?").
Well, Windows NT and descendants aren't directly derived from DOS.

Won't it, especially as libtla comes on line, make sense to support
all three if that's practical?
Short term, yes. Long term, I think it would be nice to combine Leroy's and Berg's work. Presumably, the result would require neither Cygwin nor NTFS. It might even work on the Windows 9x family.
The question from my perspective, is really the impact on the code of
any particular approach.   If it's clean and isolated or clean and
minor -- then sure, let's add it.
I agree. It's great to see the strides that have been made in porting Arch to Windows. Ultimately, I think we do want a single Windows port. Having 3 versions with essentially the same features will only lead to user confusion. But I don't think we need to pick one right away and toss the others.

Aaron




reply via email to

[Prev in Thread] Current Thread [Next in Thread]