Author Topic: Avast  (Read 5446 times)

0 Members and 1 Guest are viewing this topic.

Offline NoelC

  • Poster
  • *
  • Posts: 569
Re: Avast
« Reply #15 on: December 31, 2013, 09:56:32 PM »
What I can't figure out is what does -midnight have against Google.  ???
A lot of folks don't care for Google.  I believe their influence on the computing landscape has been bad, personally.

-Noel

Offline Randissimo

  • Full Member
  • ***
  • Posts: 132
Re: Avast
« Reply #16 on: January 01, 2014, 04:27:06 PM »
It's a little bit complicated in my opinion: If Avast would be only a pure 32bit application, the default installation path would be C:\Program Files (x86) instead of C:\Program Files.
However, it doesn't have any 64bit processes running in the task manager.

I guess it's a 32bit application which has been altered to be compatible with x64 systems so much, that Windows can't recognize it as a pure 32bit application anymore and installs it on default settings in C:\Program Files with other x86-x64 and pure x64 applications.

On a quick note, x64 processors used in current home computers are actually x86-x64 processors.

« Last Edit: January 01, 2014, 04:33:31 PM by Randissimo »

Offline NoelC

  • Poster
  • *
  • Posts: 569
Re: Avast
« Reply #17 on: January 01, 2014, 07:15:37 PM »
The installer writer gets to choose where it gets installed.  The differentiation between C:\Program Files (x86) and C:\Program Files is completely arbitrary.

-Noel

Offline Randissimo

  • Full Member
  • ***
  • Posts: 132
Re: Avast
« Reply #18 on: January 01, 2014, 09:14:41 PM »
The differentiation between Program Files and Program Files (x86) is not arbitrary:
Quote
64-bit versions of Windows have two folders for application files; 'Program Files' folder serves as the default installation target for native (in this case 64-bit) programs, while the 'Program Files (x86)' folder is the default installation target for non-native (in this case x86-32) programs. While 64-bit Windows versions also have a %ProgramFiles(x86)% environment variable, the dirids/CSIDLs are not different for 32-bit/64-bit; the setup/shell APIs merely return different results, depending on whether the calling process is native or not.
https://en.wikipedia.org/wiki/Program_Files
« Last Edit: January 01, 2014, 09:32:30 PM by Randissimo »

Offline NoelC

  • Poster
  • *
  • Posts: 569
Re: Avast
« Reply #19 on: January 01, 2014, 09:40:12 PM »
I apologize for perhaps a poor (or too terse) choice of wording on my part.

Any installer writer could choose either destination for 32 or 64 bit software.  That decision is not set or policed by any technical process that's in place - as clearly indicated by Avast's own installer - it's an arbitrary distinction, written in guideline form.

Product developers producing software that spans both architectures (32 and 64 bit) could arbitrarily choose to install parts under one subtree and parts under another, or put it all in one place.  Or even someplace else entirely, though that requires more work.

-Noel

Offline Randissimo

  • Full Member
  • ***
  • Posts: 132
Re: Avast
« Reply #20 on: January 02, 2014, 01:08:54 AM »
Any installer writer could choose either destination for 32 or 64 bit software.  That decision is not set or policed by any technical process that's in place - as clearly indicated by Avast's own installer - it's an arbitrary distinction, written in guideline form.
So it's simply like:
1. check for OS type
2. force install to %ProgramFiles% (instead of sth. like: if x64 computer and software is x64 install to %programFiles% else use %ProgramFiles (x86)% )
3. check %systemroot% and place everything depending on the OS type

Is there at least a difference with step 3 between the installed version on a x86 and on a x64 system?
Or to put it in other words: are there at least 64 bit drivers while the program and its GUI itself run completely as 32 bit processes?

jwoods301

  • Guest
Re: Avast
« Reply #21 on: January 02, 2014, 01:32:17 AM »
I don't know about other installers, but InstallShield allows you to customize the locations.

Really doesn't make sense, especially from a support standpoint, if you have to search the hard drive for the application folder, rather than jump in to Program Files (whatever).

Plus, environment variables are already set up to look for application executables in those pre-determined folders.

So even though you "can", doesn't mean it's a good idea.