Install a program on Windows 8

[NewsArchive]

Hello Friedrich and all others,

over the weekend I am playing with Windows 8 Preview 8400 a bit.

We install the binary files (all EXE/DLL/OCX code-signed and EXE manifested) of
our programs by default under "C:\Program Files\Our Folder",
the data go by default to "C:\Users\Public\Documents\Our Folder\Data".
If I am not completely wrong, we compile the installer with SB 7.5.3378.

That works fine so far.

We use some INI-files which gets stored in "C:\Program Files\Our
Folder\Settings" - which is a violation of the rules MS set up years ago, I
know.

During the install we set the R/W access-privileges to All Users, so that
settings can be modified from within our Admin.EXE, no matter if called from an
Admin or User account. That might be considered dirty..... it worked all years
- and now we get bitten ;-)

All files in that Settings folder are not editable. I can set the privileges
manually, thenit works again, but have to modify each file separately. Altering
the folder and therefore all subsequent files inside in one rush does not
work.

Do you have another, ever more dirty trick to overcome that lack? <eg>

The reason why we store the INI in a Settings folder just beyond the EXE-folder
is, that now an andmin can move the entire folder somewhere else, without
loosing anything. Often they also place the data folder below that EXE folder.
They are happy with this.

Plan B would be to check at program start, if INI exist. If not, store them in
%CSIDL_APP_DATA% or where ever and fill them with the necessary default values,
then let the Admin do set the values again.

Or you may come up with a complete different suggestion......

Thanks for reading,
Wolfgang

[NewsArchive]

Hello Wolfgang,

under-the-hood, Microsoft improved the security model and the latest Windows
8 RTM (9200) changes the behavior again (there were important changes from
#8400 to #9200).

The only suggestion I can make is that you should change your application to
an UAC-aware and Win8-compliant system. With Windows 8, the time of dirty
hacks is over <g>. Do not store writable files under a protected system
resource and do not manipulate the folder permissions. This might result in
a support nightmare sooner or later.

BTW, Windows 8 RTM (9200) works very nicely but there is no room for hacks
anymore. Without a UAC-aware application model you are lost. And it's very
important to compile the setup.exe with a Win8-compliant SetupBuilder
version. The old V7.5 is not Win8-compliant.

Friedrich

[NewsArchive]

Good tips.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

> With Windows 8, the time of dirty hacks is over <g>.

OH NO!

Wolfgang Orth

[NewsArchive]

Not to worry Wolfgang, you can still do clean hacks <g>

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

forget about program files and install in a root folder by default and
offer to use UAC compatible for those who are too microsft security
freaks .... make things easier for you

--
JP
__________________________________________________ _____

For those who do not understand ... : "Qui bene amat bene castigat."
__________________________________________________ _____

DMC - Data Management Center : a tool to let you Migrate Import Export
Transfer your Data
www.dmc-fr.com

[NewsArchive]

> forget about program files and install in a root folder by default and
> offer to use UAC compatible for those who are too microsft security freaks
> .... make things easier for you

Well, security is a good thing. A VERY good thing. Funny story: the last
three days (I have finished the project 15 minutes ago) I helped a client
who did not follow the rules and decided to install outside of the protected
"Program Files" folder. Wow, what a horrible mistake and a very expensive
one. A virus infected his application files (because all doors were wide
open outside of Program Files). The virus sent sensible data (thousands of
records and an unknown number of files) silently to servers in Russia. The
anti-virus detected the (new) Trojan last Friday, but the system got
infected 10 days ago.

Yes, I am a security freak and I know why <g>. I do not trust any software
product that is not installed in "Program Files". I'll say it again and
again. Not following the UAC development guidelines is a BIG mistake - it
can ruin your reputation!

"No dirty tricks anymore" (TM)

Friedrich

[NewsArchive]

Errr Friderich this story is fantastic but it is _only_ related to one
problem : the AV used was NOT good enough and "closing all doors" is
not a way to protect but only a "facade" to security holes in an OS
(sorry <g>)

Where the files are located is irrelevant here, no (AV problem) ?

What I see and experience is that when you use UAC compatible folders
for exe and data then you _DO_ have (on some machines) a slow down when
WRITING heavily to HD because all goes through the "big brother
protection" plus the AV one (if not defined to exclude that folder)

Nothing more , nothing less.

My installer offers the CHOICE to the user who DECIDES but the default
is to non UAC (for these reasons which ARE explained in the installer)

When a task goes down from 14 HOURS to TWO hours then I do start
wondering if the "big brother protection" is not too greedy on
ressources (on some machines) and as everybody does not have a top
notch machine latest this and that - do we need to "play the game" of
big companies who refuse this or that hardware or os in their "ways of
seing things" .... another big question <g> which will never find an
answer.

--
JP
__________________________________________________ _____

For those who do not understand ... : "Qui bene amat bene castigat."
__________________________________________________ _____

DMC - Data Management Center : a tool to let you Migrate Import Export
Transfer your Data
www.dmc-fr.com

[NewsArchive]

> Errr Friderich this story is fantastic but it is _only_ related to
> one problem : the AV used was NOT good enough and "closing all doors"
> is not a way to protect but only a "facade" to security holes in an
> OS (sorry <g>)

No, this is not a story, it is reality ;-) And you are so completely wrong
<g>. This Trojan was brand new and not any of the major anti-virus and
spyware systems detected it!

>
> Where the files are located is irrelevant here, no (AV problem) ?
>

No! In the first place this is an installation problem, not an AV problem
per-se. The virus or Trojan is available BEFORE anti-virus vendors can make
definition updates available.

> What I see and experience is that when you use UAC compatible folders for
> exe and data then you _DO_ have (on some machines) a slow down when
> WRITING heavily to HD because all goes through the "big brother
> protection" plus the AV one (if not defined to exclude that folder)
>
> Nothing more , nothing less.

JP, you can do whatever you want on your own computer system and with your
own software. If your users accept an insecure deployment strategy, okay.
I just warned others here that it is very dangerous and
more than bad practice to not follow the Windows development guidelines
(that are there for 15+ years now) in this case.

Security comes first!

> My installer offers the CHOICE to the user who DECIDES but the default is
> to non UAC (for these reasons which ARE explained in the installer)

Well, you said: "forget about program files and install in a root folder by
default and offer to use UAC compatible for those who are too microsft
security freaks .... make things easier for you"

I hope that no one who read the above will follow your advice. It's a wrong
strategy and a very dangerous one.

At least you should default to the secure folder location and offer an
option to the "suicide-mode" subfolder under the root.

> When a task goes down from 14 HOURS to TWO hours then I do start wondering
> if the "big brother protection" is not too greedy on ressources (on some
> machines) and as everybody does not have a top notch machine latest this
> and that - do we need to "play the game" of big companies who refuse this
> or that hardware or os in their "ways of seing things" .... another big
> question <g> which will never find an answer.

Again, security comes first. I can't comment on the speed difference, but I
don't think that this is a general problem. It might be application
specific. But who knows.

But hey, it's a free world and as long as the customers accept it you can do
whatever you want ;-)

Friedrich

[NewsArchive]

sure.

--
JP
__________________________________________________ _____

For those who do not understand ... : "Qui bene amat bene castigat."
__________________________________________________ _____

DMC - Data Management Center : a tool to let you Migrate Import Export
Transfer your Data
www.dmc-fr.com

[NewsArchive]

I better re-think this. Are there similar reasons with program data? I
hope not, those folders (especially roaming types) are a pain to walk.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

> I better re-think this. Are there similar reasons with program
> data? I hope not, those folders (especially roaming types) are
> a pain to walk.

The ProgramData folder only stores user writable (application) data. So no
problem here.

The "Program Files" folder tree is quite heavily protected by Windows. Only
elevated running processes can infect files that are located in such a
"secured" location.

Friedrich

[NewsArchive]

By default, ProgramData is hidden. We added a test item to our list:
re-hide it (if needed) and install on a clean machine. We decided to
simplify the paths and locations as users tend to cock this up, so we
only determine which drive they want. But our initial setup is a
Clarion app (which runs a bunch of different SB installs) which creates
the new folders. Want to make sure our create folder functions work
under these conditions.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

>Well, security is a good thing. A VERY good thing. Funny story: the last
>three days (I have finished the project 15 minutes ago) I helped a client
>who did not follow the rules and decided to install outside of the protected
>"Program Files" folder. Wow, what a horrible mistake and a very expensive
>one. A virus infected his application files (because all doors were wide
>open outside of Program Files). The virus sent sensible data (thousands of
>records and an unknown number of files) silently to servers in Russia. The
>anti-virus detected the (new) Trojan last Friday, but the system got
>infected 10 days ago.

We should pin this at the front door as a warning to all!

Again a question (sorry for bothereing you again):

Storing the data on %CSIDL_COMMON_DOCUMENTS%\MyProduct\Data is okay?

It is meant for a multi-user system, where all users should have access to the
same set of data.

tia
Wolfgang

[NewsArchive]

Hi Wolfgang,

> We should pin this at the front door as a warning to all!
>
> Again a question (sorry for bothereing you again):
>
> Storing the data on %CSIDL_COMMON_DOCUMENTS%\MyProduct\Data is
> okay?
>
> It is meant for a multi-user system, where all users should have
> access to the same set of data.

You're not bothering me at all :-)

Yes, storing per-machine databases in the COMMON_DOCUMENTS folder is okay
and the preferred location.

But read this (long thread, but very interesting):

http://www.lindersoft.com/forums/showthread.php?p=25491#post25491

Friedrich