Eagle 7.2 Win install directory -- why non-standard?

Hi Graham,

The reason we changed the default installation path is to avoid the

virtualisation issues in newer Windows (it started in Vista and then

took hold from there).

Many users don't bother to check where they save their work and often

save into EAGLE's installation directory. With the UAC features the

write get redirected without the user ever knowing.

When they try to find the files through Windows explorer they don't

appear and panic ensues. This behaviour caused us (the support staff

specifically) a lot of head aches and calls. So the decision was made to

simply change the default path to avoid the issue altogether.

One could argue that the correct solution would be to conform to Windows

file conventions and make any necessary adjustment to where our

libraries and such are stored to avoid this issue. At this time we want

to minimize any special considerations based on OS so that is the

decision we went with.

Computer savy users can usually figure out what's going and save their

work elsewhere, but unfortunately they don't make up the majority of

EAGLE users.

Basically, as long as you don't save any of your work into the

installation directories, or try to modify anything in the installation

directories then you won't have problems.

I hope this gives you some insight.

Best Regards,

Jorge Garcia

Jorge and all:

First off, thanks for filling me in on the rationale for why the change of install directory. That allows me to assess the alternatives. Here's what I think I learned.

Apparently the problem to be solved was that users were saving their docs to the default location offered by Eagle's Save dialog, which was set to point to a directory within the Eagle application directory. That has not been a reasonable location to store user docs at least as far back as WinXP, so over 13 years.

Windows has increasingly attempted to protect application directories against arbitrary writes by nonprivileged users. So in recent versions of Windows, attempts by applications (perhaps running with non-admin permissions) to save user files to their app directories have been redirected to the specific user's VirtualStore:

So, the app tries to save to C:\Program Files (x86)\EAGLE-6.5.0

Windows saves that to:

C:\Users\[user]\AppData\Local\VirtualStore\Program Files (x86)\EAGLE-6.5.0.

(I'm assuming that Eagle 6.5's Open dialog would see into the VirtualStore when opening -- that is Save and Open were symmetrical, though I have not tried it myself.)

Amongst other things, it means multiple users using the same copy of Eagle don't overwrite each other's files.

However, if users use Windows Explorer to go looking for their files where they think they put them, obviously they will be surprised.

Let's be clear, however, that this is not intended to be a good way of doing things. It is simply a way for Windows to tighten security while dealing with legacy applications that don't properly deal with saving files.

There is nothing to stop Eagle from making sure that the Save dialog defaults to some directory other than the application directory. A decent choice would be within the User's home directory:

C:\Users\[user]\Documents\Eagle

or similar. And there are OS variables that an app can use to easily determine that directory, even if the user has located it somewhere else.

Of course, a slightly more savvy user might use Eagle settings to specify a different directory, as is current practice, especially for multiple users sharing files, perhaps on a server.

The point is, on no platform should Eagle be storing user documents in the application's installation directory. Surely it doesn't do so on Mac or linux? So why would it suggest to do so on Windows?

Bottom line: from what I've heard so far, it seems to me that the change to a non-standard installation directory was primarily a coarse fix for the fine-scale issue of simply pointing the Save and Open dialogs to a sensible default location.

-- Graham

On 29.04.2015 23:10, Graham Wideman wrote:

Jorge and all:

Bottom line: from what I've heard so far, it seems to me that the change

to a non-standard installation directory was primarily a coarse fix for

the fine-scale issue of simply pointing the Save and Open dialogs to a

sensible default location.

You seen to know what you're talking about. Maybe you could explain what

Cadsoft (or users, by manually choosing non program folder) risk by

simply putting an executable onto a common folder?

Very good information.  I guess from my knothole (and many others), the

biggest problem with the "virtualization" scheme that M$ implemented is the

fact that they don't bother to tell you they didn't put your files where

you thought you put them.  Give me a pop-up indicating the specified

location is NOT legal for user files and where they are being stored.  Most

people that run into this don't have a clue what happened.  And it can be

pretty insidious at times - different software, the company sent me a new

key file by email.  I grabbed the keyfile (license) and dragged it onto the

install directory for their software (where it belonged).  Didn't work -

seems if you drag from the email, it does not have the rights to be put in

the install directory (under /Program Files(x86) ) so it puts it in the

virtual store WITHOUT telling you.  If you drag it to the desktop first

THEN to the install directory, that works (at least as an admin).  I

understand the attempt to protect the install directories, but TELL the

user you did not do what they asked, not simply do something else then say

"OK".

mikey

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Hi Graham,

I actually have an element-14 account, the problem is that I access the

newsgroups through Thunderbird and NNTP. Element14's interface to this

server is less than stellar and this is just one of it's issues.

I don't want to go through the web portal so I just deal with the

Cadsoft guest situation by writing my name in every post I write. So if

you see my name you know its me.

Best Regards,

Jorge Garcia

On 01.05.2015 11:55, Graham Wideman wrote:

By way of refining my calibration on this topic, I'd be curious what

tools those are.

Both my FPGA tools from Altera (Quartus) and Xilinx (Vivado/ISE) uses

this method. Most likely unlrelated, but common to them both is that

they contain abundance of small files (Quartus:113k5, Vivado:61k5).

It appears to me like most cross platform tools prefer their own folder

top level. But Im working on single user computer and it works fine,

wich is probably why they dont even try to change it.

But in the end, Id also like Eagle's default user files to be protected

and default paths set outside program root folder.

To Guest who replied:

> There are two versions of the Windriver / Diab C compiler for PowerPC,

> Gimpel PCLint, the Lauterbach in-circuit debugger tools, and one other

> that escapes me right now. Of those, I think the compiler can (with some

> effort) be made to work in Program Files, I'm not sure on the others.

> These are all rather elderly versions, though, so it's possible the

> recent ones are more conventional.

This is similar to my experience. As you say, in general more recent software has been following the installation plan that has been increasingly conventional (on Windows) starting around Win 2000.

> I guess the difference is that [...]

I agree that these kinds of tools come with a number of moving parts, and accumulate more as you use them. There's always a tension between the desire to keep all parts pertaining to a particular tool together in the directory structure, versus distributing those parts according to categories of "applies to all users" vs "applies to one person", and to the categories of security that can be applied. Those three priorities are often not apparent nor well understood by users, and sometimes not be developers either.

> On Windows 9x this was less clear, so top level install was common.

Hopefully decisions are no longer being made on the basis of supporting Win 9x!  :-)

Hi CadSoft Jorge

Sorry I mistook one Guest for another. Jorge, haven't you been around long enough to earn your own account? :-).

On 01/05/15 10:55, Graham Wideman wrote:

At least four of the commercial tools I use at work install this way

By way of refining my calibration on this topic, I'd be curious what

tools those are. I, too, have numerous software development tools,

including embedded and desktop IDEs and build systems, and I believe

virtually all are capable of installing in Program Files, though I don't

dispute that there are some tools that can't.

 

There are two versions of the Windriver / Diab C compiler for PowerPC,

Gimpel PCLint, the Lauterbach in-circuit debugger tools, and one other

that escapes me right now. Of those, I think the compiler can (with some

effort) be made to work in Program Files, I'm not sure on the others.

These are all rather elderly versions, though, so it's possible the

recent ones are more conventional.

I haven't listed the half-dozen automotive / motorsport specific tools

that also default to top-level installation, nor the SDKs for embedded

OS's, because they're too specialist to count as "commercial", even

though they are sold for non-trivial amounts of money.

I guess the difference is that these are all tools which consist of

quite a lot more than just some executables. Compilers come with a bunch

of standard headers and libraries, debuggers have configuration scripts

and flash programming algorithms. Also, these are files that the tool's

user needs to know about, and probably inspect, possibly even modify. On

Unix they would need to install into a number of different defined

locations (/usr/bin, /usr/share/, /etc/) or to a defined "non-core"

place like /opt. On Windows 9x this was less clear, so top level install

was common.

On 01/05/15 10:55, Graham Wideman wrote:

At least four of the commercial tools I use at work install this way

By way of refining my calibration on this topic, I'd be curious what

tools those are. I, too, have numerous software development tools,

including embedded and desktop IDEs and build systems, and I believe

virtually all are capable of installing in Program Files, though I don't

dispute that there are some tools that can't.

 

There are two versions of the Windriver / Diab C compiler for PowerPC,

Gimpel PCLint, the Lauterbach in-circuit debugger tools, and one other

that escapes me right now. Of those, I think the compiler can (with some

effort) be made to work in Program Files, I'm not sure on the others.

These are all rather elderly versions, though, so it's possible the

recent ones are more conventional.

I haven't listed the half-dozen automotive / motorsport specific tools

that also default to top-level installation, nor the SDKs for embedded

OS's, because they're too specialist to count as "commercial", even

though they are sold for non-trivial amounts of money.

I guess the difference is that these are all tools which consist of

quite a lot more than just some executables. Compilers come with a bunch

of standard headers and libraries, debuggers have configuration scripts

and flash programming algorithms. Also, these are files that the tool's

user needs to know about, and probably inspect, possibly even modify. On

Unix they would need to install into a number of different defined

locations (/usr/bin, /usr/share/, /etc/) or to a defined "non-core"

place like /opt. On Windows 9x this was less clear, so top level install

was common.

To Guest who replied:

> There are two versions of the Windriver / Diab C compiler for PowerPC,

> Gimpel PCLint, the Lauterbach in-circuit debugger tools, and one other

> that escapes me right now. Of those, I think the compiler can (with some

> effort) be made to work in Program Files, I'm not sure on the others.

> These are all rather elderly versions, though, so it's possible the

> recent ones are more conventional.

This is similar to my experience. As you say, in general more recent software has been following the installation plan that has been increasingly conventional (on Windows) starting around Win 2000.

> I guess the difference is that [...]

I agree that these kinds of tools come with a number of moving parts, and accumulate more as you use them. There's always a tension between the desire to keep all parts pertaining to a particular tool together in the directory structure, versus distributing those parts according to categories of "applies to all users" vs "applies to one person", and to the categories of security that can be applied. Those three priorities are often not apparent nor well understood by users, and sometimes not be developers either.

> On Windows 9x this was less clear, so top level install was common.

Hopefully decisions are no longer being made on the basis of supporting Win 9x!  :-)