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

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > 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)


Right.  So, my ignorance stops me from drawing definate conclusions
about some of that.

Won't some users continue to not want to use NTFS for the forseeable
future, making Leroy's worth keeping?  (But I note your comments about
combining Leroy and Berg's work, below.)

And while some users won't care, Berg's involves depending on one less
piece of non-free software (SFU).

Finally, won't the SFU approach be (technically) the "smoothest" in
some environments?   (And, for that matter, does it actually require
any changes beyond the kinds of tweaks you'd expect from porting to
some unusual Unix environment?)

Which is why I was thinking that all three, so long as the impact is
not nasty, are worth supporting.



    > >("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.

Yes, I know (although, don't they still contain some compatability
code or is that gone by now?).   As I said, not _much_ of an
exaggeration. :-)


    > >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. 

NTFS doesn't have the long path problems, right?   I think it would be
nice (if it isn't impractical, anyway) to continue to provide NTFS
support that doesn't rely on SFU -- though, sure, that could be
integrated with path compression for other file systems.   Sounds good
and might also eventually help to port _other_ hackerlab-based
software to Windows environments (our own little APR-type-thingie).

Another ignorant question: am I right in understanding that NTFS uses
a UTF-16 encoding for filenames?   That's potentially a very useful
obstacle since I'd like to get the VU layer in hackerlab to a point
where it presents a UTF-8 filesystem to the application but maps that
to whatever the host happens to use.


    >> 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.

Absolutely.   If nothing else, I think it is a _major_ impedement to
(anyone, not just me) developing commercial services around arch.
  
    > 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.

Good.  Yeah, I see it as an instance of non-deterministic game playing
in a situation of partial knowledge.  If the practical opportunity is
there to persue multiple plausible strategies in parallel at a time
when it isn't clear which is best then doing so maximizes the
potential of developing the most winning strategy(-ies).

I think the Big Awkwardness right now is going about merging stuff
back into the mainline.  Since I don't have (and don't want to have)
environments on which to test the changes, all I can review for is
cleanliness and lack of negative impact on unix environments.
Basically, I have to merge this stuff nearly blind and just accept
people's reports about whether it's working or not on those platforms.

-t