On 2017-11-20 12:17, Koen Piller wrote:

> What is the directory of app not C:/Program Files (86) I hope

> Rgds

> Koen

Oh hell no....I haven't deployed to Program Files for YEARS. Many here

will tell you that you avoided so many M$ problems by installing in your

own app folder off the root (C:\MBSS) instead of following M$'s advice.

Chime in all, if you want to give an "amen" for that.

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/89b96bcd71ba41638f71f8c4cb7062e3@mbsoftwaresolutions.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

I agree with you, I do not install anything in Program Files or other

Microsoft suggested locations. In fact, I've been building old school style

for a while now. Where possible, I am installing all files in my own folders

including avoiding installing anything in the Registry. You all will

probably laugh at this strategy, but hear me out.

Yes, there is a Santa Clause and yes, I still store settings in .INI files.

Here's why: I write software utilities that often have to be moved by

clients either between computers or from local drives to network shares. All

my data is stored in a sub-folder below the program installation folder as

are all supporting files. Main program files and settings files are stored

in the program installation folder, including MSVCR71.DLL and MSVCP71.DLL to

support vfpcompression.fll and other elements like the VFP runtimes also

stored in my main program folder. The only files I install outside of this

main folder or subfolders are MSCOMCT2.OCX and MSCOMCT2.SRG which provide

the Calendar popup I use (and one day when I have nothing else to do, I'll

find a replacement I like and get rid of that too, but in the meantime I

include an installer just for that if the user happens to move our program

and need the OCX installed.)

The IT admins that I work with have told me explicitly that they love the

flexibility our method of programming gives them particularly in a corporate

environment where change is a given. They can move our programs by copying a

single folder and updating a shortcut. They can add a new user by creating a

shortcut and they can change a server or workstation out without breaking

our program. AND, they can back up one folder and if there is a crash, copy

that folder to a new hard drive and start running the application

immediately.

I've never bought in to the whole idea of storing my stuff in someone else's

environment. Laugh if you like, but it works for me and it works for my

clients. Obviously, building a true Client-Server system requires different

mindset since you'll need a database server, but for what I make the most

money on today, my strategy works for me.

Paul H. Tarver

Email: paul@tpcqpc.com

-----Original Message-----

From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of

mbsoftwaresolutions@mbsoftwaresolutions.com

Sent: Monday, November 20, 2017 11:20 AM

To: profoxtech@leafe.com

Subject: Installing in your OWN folder instead of under Program Files (was

Re: AW: VFP9 latest service pack (9.0.0.7423))

On 2017-11-20 12:17, Koen Piller wrote:

> What is the directory of app not C:/Program Files (86) I hope Rgds

> Koen

Oh hell no....I haven't deployed to Program Files for YEARS. Many here

will tell you that you avoided so many M$ problems by installing in your

own app folder off the root (C:\MBSS) instead of following M$'s advice.

Chime in all, if you want to give an "amen" for that.

[excessive quoting removed by server]

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/038201d36229$a6ed0a10$f4c71e30$@tpcqpc.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

On 2017-11-20 13:01, Paul H. Tarver wrote:

> I agree with you, I do not install anything in Program Files or other

> Microsoft suggested locations. In fact, I've been building old school

> style

> for a while now. Where possible, I am installing all files in my own

> folders

> including avoiding installing anything in the Registry. You all will

> probably laugh at this strategy, but hear me out.

>

> Yes, there is a Santa Clause and yes, I still store settings in .INI

> files.

> Here's why: I write software utilities that often have to be moved by

> clients either between computers or from local drives to network

> shares. All

> my data is stored in a sub-folder below the program installation folder

> as

> are all supporting files. Main program files and settings files are

> stored

> in the program installation folder, including MSVCR71.DLL and

> MSVCP71.DLL to

> support vfpcompression.fll and other elements like the VFP runtimes

> also

> stored in my main program folder. The only files I install outside of

> this

> main folder or subfolders are MSCOMCT2.OCX and MSCOMCT2.SRG which

> provide

> the Calendar popup I use (and one day when I have nothing else to do,

> I'll

> find a replacement I like and get rid of that too, but in the meantime

> I

> include an installer just for that if the user happens to move our

> program

> and need the OCX installed.)

>

> The IT admins that I work with have told me explicitly that they love

> the

> flexibility our method of programming gives them particularly in a

> corporate

> environment where change is a given. They can move our programs by

> copying a

> single folder and updating a shortcut. They can add a new user by

> creating a

> shortcut and they can change a server or workstation out without

> breaking

> our program. AND, they can back up one folder and if there is a crash,

> copy

> that folder to a new hard drive and start running the application

> immediately.

>

> I've never bought in to the whole idea of storing my stuff in someone

> else's

> environment. Laugh if you like, but it works for me and it works for my

> clients. Obviously, building a true Client-Server system requires

> different

> mindset since you'll need a database server, but for what I make the

> most

> money on today, my strategy works for me.

Hi Paul,

My strategy is very similar to yours. I still use INI files and they

work great for the reasons you stated!

--Mike

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/92846b394635a581a3c4c18df47f5594@mbsoftwaresolutions.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

Glad to know I'm not in the wilderness on that point! :)

Paul H. Tarver

Email: paul@tpcqpc.com

-----Original Message-----

From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of

mbsoftwaresolutions@mbsoftwaresolutions.com

Sent: Monday, November 20, 2017 12:12 PM

To: profoxtech@leafe.com

Subject: Re: Installing in your OWN folder instead of under Program Files

(was Re: AW: VFP9 latest service pack (9.0.0.7423))

On 2017-11-20 13:01, Paul H. Tarver wrote:

> I agree with you, I do not install anything in Program Files or other

> Microsoft suggested locations. In fact, I've been building old school

> style for a while now. Where possible, I am installing all files in my

> own folders including avoiding installing anything in the Registry.

> You all will probably laugh at this strategy, but hear me out.

>

> Yes, there is a Santa Clause and yes, I still store settings in .INI

> files.

> Here's why: I write software utilities that often have to be moved by

> clients either between computers or from local drives to network

> shares. All my data is stored in a sub-folder below the program

> installation folder as are all supporting files. Main program files

> and settings files are stored in the program installation folder,

> including MSVCR71.DLL and MSVCP71.DLL to support vfpcompression.fll

> and other elements like the VFP runtimes also stored in my main

> program folder. The only files I install outside of this main folder

> or subfolders are MSCOMCT2.OCX and MSCOMCT2.SRG which provide the

> Calendar popup I use (and one day when I have nothing else to do, I'll

> find a replacement I like and get rid of that too, but in the meantime

> I include an installer just for that if the user happens to move our

> program and need the OCX installed.)

>

> The IT admins that I work with have told me explicitly that they love

> the flexibility our method of programming gives them particularly in a

> corporate environment where change is a given. They can move our

> programs by copying a single folder and updating a shortcut. They can

> add a new user by creating a shortcut and they can change a server or

> workstation out without breaking our program. AND, they can back up

> one folder and if there is a crash, copy that folder to a new hard

> drive and start running the application immediately.

>

> I've never bought in to the whole idea of storing my stuff in someone

> else's environment. Laugh if you like, but it works for me and it

> works for my clients. Obviously, building a true Client-Server system

> requires different mindset since you'll need a database server, but

> for what I make the most money on today, my strategy works for me.

Hi Paul,

My strategy is very similar to yours. I still use INI files and they work

great for the reasons you stated!

--Mike

[excessive quoting removed by server]

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/03f301d3622f$9e292d40$da7b87c0$@tpcqpc.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

On 11/20/2017 12:20 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:

> Oh hell no....I haven't deployed to Program Files for YEARS.  Many

> here will tell you that you avoided so many M$ problems by installing

> in your own app folder off the root (C:\MBSS) instead of following

> M$'s advice.  Chime in all, if you want to give an "amen" for that.

>

Amen.

The best "architectural" decisions I've made on the Windows platform

have been those that have directly contradicted Microsoft "best

practice" statements.

Of course, when I mean best decision, I'm evaluating based on ease of

deployment, maintenance, upgrade, and error-tracing. Many of my

applications have run since Windows 98. Apart from coding to take

advantage of newer VFP features, I pretty much never had to spend time

fixing the design because of something MS did (although around the time

of Vista there was MessageBox() weirdness and "ghost" files...). I

compare that to what I've seen in massive rewrites of COM+,

Net<something... right after COM+?>, IE (browser-based) code (but

browsers were supposed to save us from that???!!! - ROFLMAO) - all

because of Windows version changes (or even just IE changes).

But, in agreement with Ted, if I was solely out to just keep a job due

to MS-created breakage, my decisions were probably not the best.

Hmmm.... I wonder if MS labeled those things as "best practices" because

they were best for MS: as in the best way to lock-in development staff

on Windows (play on laziness and lack of computer science knowledge),

and therefore lock-in the user base. Maybe MS wasn't as stupid as they

appeared to be.... Nah.

-Charlie

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/a47479f1-89d4-9ea3-3ca2-d69574dbd325@gmail.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.