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

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

gpsmikey — Sat, 06 Jun 2015 14:50:36 GMT

Yeah, I was trying to figure out just where we were going with that (although my son IS an Eagle Scout ! )

mikey

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

clem57 — Sat, 06 Jun 2015 14:16:11 GMT

Eagle software is not a eagle scout form. LOL

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

e14 Contributor — Sat, 06 Jun 2015 13:53:27 GMT

If anyone needs to fill out a eagle application, I found a blank form here: EAGLE SCOUT RANK APPLICATION Fill Online, Printable, Fillable, Blank - PDFfiller

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

gpsmikey — Wed, 06 May 2015 21:12:56 GMT

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.

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

autodeskguest — Mon, 04 May 2015 15:50:05 GMT

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

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

autodeskguest — Mon, 04 May 2015 07:06:33 GMT

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.

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

gwideman — Fri, 01 May 2015 21:57:49 GMT

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

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

gwideman — Fri, 01 May 2015 21:45:31 GMT

Hi CadSoft Jorge

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

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

autodeskguest — Fri, 01 May 2015 21:17:32 GMT

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.

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

autodeskguest — Fri, 01 May 2015 16:20:57 GMT

Just to clarify, the last comment wasn't by me, it was Rob but

element-14 shows all of our posts as Cadsoft Guest which isn't very helpful.

If there's anything I can do for you, let me know.

Best Regards,

Jorge Garcia

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

gwideman — Fri, 01 May 2015 09:55:43 GMT

Hi Jorge,

First, let me say I'm not "utterly up in arms" about this situation. I was just trying to get to the bottom of why Eagle was not using the commonest (by far) convention for installing apps on Windows, and if I choose to use the commonest convention, is there a downside. Some of the reasons offered seemed not to hold water, so I pursued them, still in hopes of learning some more solid explanation, which you kindly supplied (Eagle suggesting to users to save files in the application directory).

I am now satisfied that there probably isn't any more serious problem, at least for me, so my question is substantially answered.

> I'm rather amazed you've not encountered it before.

I have indeed encountered it, as an earlier comment of mine remarked regarding my main dev machine, and sometimes also on the many other machines I come in contact with. It's sometimes true of software that doesn't have a proper installer, for example, or attempts to maintain a directory layout that parallels that of the app's unix counterpart. I also sometimes deliberately install somewhere else, for example on another drive for disk space considerations.

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

> Maybe you never had to deal with WinXP or before.

Used XP from the time it came out (as I had already been using NT 4/Win2K), until after Win 7 appeared. I'm not clear how that impacts things -- perhaps you're saying that the directory choices that make sense on Vista/Win7/Win8 aren't available on XP?

> I agree that Eagle's default installation gets it wrong in setting the default

> "Project" directory to somewhere within the installation.

OK, great, I think fixing that would be a good improvement.

Anyhow, thanks for the conversation,

-- Graham

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

autodeskguest — Fri, 01 May 2015 07:01:38 GMT

On 01/05/15 00:40, Graham Wideman wrote:

If an
application randomly creates a top-level directory on C:, I have no idea
what that's about. Is it a temp directory, useful only during
installation, or during obscure operations, that can deleted? Or is it a
vital part of some application.

As I said, it's a common convention for Windows applications. At least

four of the commercial tools I use at work install this way (and Eagle

is not one of them - I'm a software engineer in that job). In every

case, a top level directory is where the application lives. I'm rather

amazed you've not encountered it before.

Maybe you never had to deal with WinXP or before. I grant that most of

the big Windows-only software houses have now followed the more common

standard and most of those cope with virtualisation sensibly, at least

in the later versions of applications. But what you are so utterly up in

arms about was and still is fairly common in the less mainstream market

- particularly with tools available on multiple platforms (I'm thinking

of cross-compilers for embedded processors, other CAD tools, traditional

software tools like "Lint", etc.)

Also, I agree that Eagle's default installation gets it wrong in setting

the default "Project" directory to somewhere within the installation.

Even the library directories should not point there. These things are

wrong on the Linux version too, and need to be corrected when first

used. But that's got nothing to do with installing in root (except, of

course, that if the mistake had never been made, the virtualisation

probably wouldn't have bitten)

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

gwideman — Thu, 30 Apr 2015 23:40:36 GMT

Hi Jorge,

> Maybe you could explain what Cadsoft (or users, by manually choosing non program folder)

> risk by simply putting an executable onto a common folder

A fair question for a software developer to understand to some level of confidence when configuring an installer. A question better addressed by the documentation for the platform rather than me, but here's my 2c.

1. Consistency with the way things are normally done on that platform. This allows users and admins to more readily understand the structure of the application. For example, if I'm admin'ing a Windows platform, I know what kinds of things I'll find in the standard locations. If an application randomly creates a top-level directory on C:, I have no idea what that's about. Is it a temp directory, useful only during installation, or during obscure operations, that can deleted? Or is it a vital part of some application.

It's one thing if I was the person doing the install. But if I'm an admin who comes along later, and don't know what Eagle is, then having Eagle's executables in a top-level directory on C: makes it look like some kind of mistake or installation that went wrong.

Also, the rational for Eagle's not-in-Program Files installation is to avoid security settings that disrupted Eagle's behavior of suggesting the users store their user docs in the app directory. That's a non-standard place for user docs, so again it defeats normal practice, this time for dealing with user docs. For example, if I want to back up someone's vital documents, I don't go looking for them in an application directory!

2. Cooperation with Windows security efforts. The issue that Eagle was apparently stumbling upon, absence of user-level write permission in application directories, is there for a good reason. It prevents applications that are running with user-level privileges from modifying executables and propagating viruses by that method. Moving your executables to a no-permission-required location defeats that protection, such that it is.

As some indication of the recommended standard locations for different types of files (executable; application non-user-interactable system wide and per-user; user docs, private and shared) the Windows Logo requirements are one source. That they are specified in the Logo requirements is a good indication that they are widely followed and expected, even if you are not seeking Logo certification.

https://msdn.microsoft.com/en-us/windows/desktop/dd203105.aspx "Review the Requirements":

=============================================

[Item number 2] Install to the correct folders by default

Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an application to the location they choose. It is also necessary to store application data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings.

Windows provides specific locations in the file system to store programs and software components, shared application data, and application data specific to a user:

-- Applications should be installed to the Program Files folder by default. User data or application data must never be stored in this location because of the security permissions configured for this folder

-- All application data that must be shared among users on the computer should be stored within ProgramData

-- All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in Users\<username>\AppData

-- Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as fonts or drivers

-- In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no correct user location to store data at time of installation. Attempts by an application to modify default association behaviors at a machine level after installation will be unsuccessful. Instead, defaults must be claimed on a per-user level, which prevents multiple users from overwriting each other's defaults.

=============================================

See also this blog post "Where Should I Write Program Data Instead of Program Files?" from seven year ago which covers many of the same concerns. The comments are also interesting.

http://blogs.msdn.com/b/cjacks/archive/2008/02/05/where-should-i-write-program-data-instead-of-program-files.aspx

Note especially the distinctions between application config data (whose files users don't usually interact with directly), and documents (schematics and PCBs in Eagle) that users definitely do want to get their hands on. Also the distinction between files private to a user, and those to be shared.

Finally, I should say that I am aware that a schematic/PCB package encounters some special challenges, because it's not just an application which allows users to create documents. Instead, there's the additional level of "libraries", which act partly as a mostly-read-only resource (hence like part of the app) but can be modified and extended by users (hence like documents), and both documents and libraries may be shared with other users. However, that isn't too different from MSWord, Excel, Visio and so on which have application, templates and libraries (supplied, and you can make your own), and user docs.

There can still be a clear location for these different files that corresponds to how they are used. Some possible defaults:

Application and supplied read-only libraries : App directory

User's projects and libraries: C:\Users\[user]\Eagle subdir.

Shared projects and libraries: C:\Users\All Users\Eagle subdir. (or possibly C:\Users\Public\Eagle)

App's settings, global: C:\ProgramData\Cadsoft\Eagle

App's settings, per-user: C:\Users\[user]\AppData\[Local or Roaming]\Cadsoft\Eagle (as now)

And of course, the user is free to change these setting according to workflow. Especially projects and libraries that might be on a network to share with others.

This is by no means the definitive word on the subject, but I hope it helps,

-- Graham

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

autodeskguest — Thu, 30 Apr 2015 06:00:06 GMT

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?

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

gwideman — Wed, 29 Apr 2015 21:10:05 GMT

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

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

autodeskguest — Wed, 29 Apr 2015 16:55:00 GMT

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

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

autodeskguest — Wed, 29 Apr 2015 11:34:08 GMT

My guess is that, since EAGLE is cross platform, Cadsoft is trying to

minimize the code that they have to change for portability. It may be

that, since they're such a small shop, they might not have the

cross-platform expertise to know or use each different operating system's

idioms.

I personally don't ever use the EAGLE installation program. I extract each

version into its own directory and make a shortcut on my desktop for each

version. The first thing I do when starting a new version is to set paths

properly to find my scripts, libraries, design rules, etc.

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

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

autodeskguest — Wed, 29 Apr 2015 10:46:15 GMT

Am 29.04.2015 um 10:32 schrieb Graham Wideman:

Clem --

YIKES thanks for prompting me to check. I still have 6.5 installed, and
I see that 7.2 is just using the same Libraries path as 6.5! So I'm not
getting the benefit of any new libraries that came with 7.2.

Apparently the two versions share the same settings file:
C:\Users\[username]\AppData\Roaming\CadSoft\EAGLE\eaglerc.usr

Pros and cons to that, I suppose.

-- Graham

--
To view any images and attachments in this post, visit:
http://www.element14.com/community/message/148488

I (must) use different versions of eagle on the same windows. Just use

the -U option and install in different paths.

Mit freundlichen Grüßen / With best regards

Joern Paschedag

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

gwideman — Wed, 29 Apr 2015 08:32:59 GMT

Clem --

YIKES thanks for prompting me to check. I still have 6.5 installed, and I see that 7.2 is just using the same Libraries path as 6.5! So I'm not getting the benefit of any new libraries that came with 7.2.

Apparently the two versions share the same settings file: C:\Users\[username]\AppData\Roaming\CadSoft\EAGLE\eaglerc.usr

Pros and cons to that, I suppose.

-- Graham

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

clem57 — Wed, 29 Apr 2015 08:00:40 GMT

I believe it is no problem as long as the short cut you use has the correct current directory to where you moved the library. This is windows standards that all programs follow including Eagle.

Clem

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

gwideman — Wed, 29 Apr 2015 07:32:15 GMT

Cadsoft Guest

I am trying to find out what breaks if I install Eagle under C:\Program Files (x86).

I am not very convinced that the Windows file system is that broken, nor that it's commonplace for apps to ignore the conventions. I have over 200 applications installed of all sorts -- consumer apps, developer tools, graphic and video tools, specialized science and engineering tools. Somehow all but about three of them manage to install and run properly, don't offer to save end-user files in the application directories, and files don't go missing.

Regardless, if you don't like to install software in \Program Files, that's fine.

What I want to know is what, if anything, breaks if I do install Eagle in the \Program Files (x86) ?

-- Graham

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

autodeskguest — Wed, 29 Apr 2015 06:56:18 GMT

On 29/04/15 06:44, Graham Wideman wrote:

Joern: Thanks for replying, but your comment does not reconcile with how
programs are customarily installed on Windows. There has historically
been a \Program Files directory, and in 64-bit Windows there's also a
\Program Files(x86) directory. These are usually on the first hard
drive, which is usually called "C:". But installers don't have to know
any of that, because they can use a shell variable %programfiles% or
%programfiles(x86)%, which deals with the possibility of a non-standard
file layout. Applications are almost never installed to a user's home
directory (though a script might be).

The problem is Microsoft's, not Cadsoft's

The historical convention you talk about results in a lot of

user-editable files living under either Program Files or Program Data.

However, recent Windows versions have rendered those folders "special" -

not user writable and kuldged with a ghastly (incomprehensible,

problematic) virtualisation scheme. Applications which follow the

historical approach therefore suffer from bizarre problems, like files

the user has saved apparently vanishing, or simply failing to save.

Eagle's more recent default of installing at the root level is, in any

case, not the horror you seem to think it is. It's almost as common as

the Program Files one, and avoids a lot of the virtualisation crap.

If you want your applications installed in sensible places, working

correctly for all users, without ugliness... then you need to run a

different OS.

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

gwideman — Wed, 29 Apr 2015 05:44:12 GMT

Joern: Thanks for replying, but your comment does not reconcile with how programs are customarily installed on Windows. There has historically been a \Program Files directory, and in 64-bit Windows there's also a \Program Files(x86) directory. These are usually on the first hard drive, which is usually called "C:". But installers don't have to know any of that, because they can use a shell variable %programfiles% or %programfiles(x86)%, which deals with the possibility of a non-standard file layout. Applications are almost never installed to a user's home directory (though a script might be).

So if there's a reason for Eagle offering/suggesting to install in its own top-level directory, it's not because it's too difficult for the installer to figure out the conventional place to install.

-- Graham

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

autodeskguest — Wed, 29 Apr 2015 05:22:39 GMT

Am 29.04.2015 um 06:21 schrieb Graham Wideman:

Hi all,

I went to install Eagle 7.2, and immediately got stuck when it offers a
default install directory of C:\EAGLE-7.2.0. OK, why?

In general I don't want apps installing themselves in random top-level
locations; why can't Eagle just install in one of the standard
locations?

So, I could just edit the suggested location, but to which standard
location? Is Eagle a 32-bit app or a 64-bit app? And maybe there's some
crucial reason why it can't be installed to one of those?

Eventually I found online a file "v7.2_en.pdf" EAGLE Update Information,
which contains the enigmatic remark "On Windows the default installation
path in the setup dialog has been changed from the Windows program
folder to C:\EAGLE-<version> (<version> being the full EAGLE version
string)."

No explanation of why this change, and how crucial it is to abide by it.
Maybe it's just a mistake?

FWIW, I changed the path to C:\Program Files (x86)\EAGLE-7.2.0. Even
doing that was a hassle because the Browse window won't allow you to
browse then enter the name of the new installation directory. But it is
possible to back out of that window and enter the desired path by hand.

After installation, I checked the eagle.exe executable, and it is a
32-bit app, so I guessed correctly on the location.

Still don't know if this will cause problems downstream though.

Any further info on this?

-- Graham

--
To view any images and attachments in this post, visit:
http://www.element14.com/community/message/148455

I think for making an installation easy, there must a path be given.

But how should eagle know how many hard disks you have and how they are

named?

Then think of the structure of windows. There is the admin account and

the users account which are different protected by the way.

As a user the program will be ready under "username" and that's one

reason why some people do not find their files

Install your program on any drive i.e. F:\eagle-xy and not under

c:\users, adjust the path in the control panel options and you are done

Mit freundlichen Grüßen / With best regards

Joern Paschedag