----- Ursprüngliche Nachricht -----
Von: Aaron Spike
An: Mike Van Emmerik
Gesendet am: 23 Feb 2011 16:07:29
> NTFS only sort-of supports hard links - you can use them, but you will
> quickly confuse other windows programs (including Explorer). It's like
> support for having multiple files in a directory that differ only by the
> letter cases. It's a feature that was put into NTFS so that MS could
> tell businesses "NTFS has support for posix - you can easily migrate
> your UNIX software to Windows NT". As soon as businesses got hooked on
> Windows NT, most of the pretence of posix compliance was dropped.
That's not entirely true. Sure, the implementation is different (it's NTFS and
not EXTx),
but the support is there and it does not confuse anyone.
Juse the explorer does not offer a frontend for this.
NFTS also supports real linked folders (not just these pseudo-links) called
junctions,
but the only point in WIndows where it is used (and a frontend is provided) is
for linking
partitions (or USB devices etc.) into an existing NTFS folder.
However, there's an excellent explorer extension that implements context menu
support as well as visual feedback and a properties dialog.
It's called "NTFS Link" and does a wonderful job. I use it all day.
No problems in daily use (it can even automatically update links if you rename
the destination folder). The only problem I ever encountered was when I changed
the drive letter of a drive. Then Win7 had problems when It tried to follow the
junctions.
>> I have yet to see the "dreaded cygwin1.dll problem" in practice. You may
>> possibly have to add cyggcc* and NLS dlls if you leave NLS enabled, but
>> that's about it.
> The "cygwin1.dll" problem applies to a number of other dll's included
> with Cygwin, depending on what the application actually uses.
> The problem occurs when you have more than one cygwin program running at
> a time, and they attempt to use different cygwin1 dll's (or other
> dll's). For most windows programs, it isn't a problem that two programs
> load different versions of the same dll - both get loaded, and they are
> kept separate. You don't get the advantage of sharing, but both
> programs work. Cygwin, for some reason (I'm sure it's a good reason -
> perhaps for implementing IPC), will not allow more than one copy of each
> dll to be loaded at a time. This means that if you have a program
> running with one version of cygwin1.dll loaded, and try to start a
> second program with a different version, it will fail.
It happened for me when isntalling AVR-Studio, whcih also installes Cygwin.
And it' snot only about running two programs at the same time.
Another problem is the linux-like behavior to not look at the current folder
first.
This way, the cygwin is loaded form the location that was put into the search
path by the program that was installed last (or first, depending on where the
path is added - in front or a tthe end of the existing one)
If this happens, both programs will always load only one isntallation, which
is not necessarily the one required (because maybe older).
Inm case of AVR Studio, it caused mspgcc top always load it way older
cygwin version, which of course lead to a crash.
Luckily there is no problem running AVR studio with the newer release.
So after some manual tweaking things work.
If the programs would look in their local installaiton folder first isntead of
only checking the global search path only, there were no problem and
they would find and execute their own installation rather than a possibly
completely different one.
I know all the reason why this is done, and they apply perfectly to Linux,
but under Windows, the base philosophy is different and this way of
searching for executables is, well, at least of limited compatibility.
>> None of the persons speaking about this "dreaded cygwin1.dll problem"
>> has so far been able to provide me with a reproducible "cygwin1.dll
>> problem" that wasn't in itself an administrative problem, and I have yet
>> to see a situation where I would be required to load two different
>> cygwin1.dll versions at the same time.
>Well, if by "administrative problem" you mean it can be fixed by an
>appropriate amount of deleting extra cygwin dll's, updating a single
>common copy, getting paths correct, etc., then yes, "cygwin1.dll"
>problems are almost always "administrative" problems. But they are
>still a pain and a waste of time and effort for someone who knows what
>they are doing - and much worse for people who don't know what is going on.
This description 'hits the nail on the head'. And I fully agree.
The problem is, that the average WIndows user is no administrator.
He expects that a program installs and runs and does not conflict with others.
Porting Linux applicaitons to Windows should not mean porting the need
to be a skilled admin from Linux to Windows.
In case of Cygwin, however, it does. Which isn't a problem for a skilled admin,
but is a problem for an average Windows user.
And in case of mspgcc, the fact that someone is (or want sto become) and
MSP developer does not make him a PC admin. And should not require it.
JMGross
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
