Randem Systems Support Board

There is no flaw... Research it and you will see that Windows 98 doesn't support a lot of things. What Windows 98 doesn't support does not constitute a flaw for Microsoft calls that do not work on said system...
 
You can argue with Microsoft on that one...

There is no such thing as one solution fits all just one solution fits most...
 
Last comment on the project code: A flawed solution doesn't fit most anybody.  It's clear that there's a flaw in the code with respect to Win98.  In the least, if the produced output is a reflection of a particular system situation, the reason(s) for that output should be communicated in some way.  The output I received doesn't convey anything about what caused it.

Yes, you still need to do some of the work as with everything. There is no such thing as one solution fits all just one solution fits most...
 
That would be my suggestion... to test in the environment you want to deploy.

Not to be combative, but I believe it was you who encouraged me to support ALL systems vis the project code rather than hard-code the {commonappdata} paths I know for sure for Win2K, XP and Vista.  Now you me, at least implicitly,  to forget about 95 and Me.
 
As for used properly and you must do some of the work, what's that all about?  What does used properly mean with respect to a program than one is simply supposed to run to receive information?  Does doing some work mean I'm supposed to debug code that presents limited, unidentified and unintelligible output (I could call it garbage output) on a Win98 system (at least mine) that is different than what it provides on other systems?  
 
Enough.  Here's what I'm going to do.  If Inno Setup Support can tell me what path {commonappdata} generates for WinMe, I'll support both 98 and Me.  Otherwise, I'm just going to support Win2K, XP and Vista.

It is all I thought it was... Used properly it will give you everything. You must do some of the work.
 
I don't deploy to 95 or Me for they were really bad OS and I would not support either. MS won't even support either...

I don't know about Me I never use it and if I wanted to deploy to it I would just test on it.
 
Easily said but I don't have, and don't know where to get access to, an WinMe machine.  Perhaps Google or the Microsoft KB can help (but I doubt the latter).
 
Again, why doesn't the project code show all the parameters?  It looks as though this code isn't all you thought it was.
 
I'll explore options in Inno Setup.

To find out, In the project code all you need to do is change the message box to show the parameter in front of the actual data.
 
I don't know about Me I never use it and if I wanted to deploy to it I would just test on it.
 
In Inno Setup you could probably display a message box with the parameter you want to know about or you can just write the data to an ini file.

New news after a thought wave.  I searched for one of the files that Setup installs.  It's in C:WINDOWSAll UsersApplication DataGHMDATA.  So obviously there's a disparity between what the project code presented and what Setup derived via {commonappdata}.
 
I guess I'm going to have to transport my project to the Win98 machine and use some test code to see what the project code returns.  Or, is there some way Inno Setup can provide what it uses for {commonappdata}?  Whichever, the question about WinMe remains.

Find out which parameter gave you that
 
I'm not sure how to do that given what was output from the project code in a standalone run.  Given the DATAPATHCODE content in the first line of the output it seems logical that Local SettingsTemp is the data path.  What's not shown is that Local Settings is a subfolder of the Windows folder.
 
So yes, if I knew that Local SettingsTemp is the data path for W98 I could recognize it and change it to WindowsLocal SettingsGHMDATA.  What about WinMe?  If it's the same as Win98, no problem.  If it's not the same, I need to know what it is.  Do you know?
 
Of course, my other less desirable option is not to support Win98 and WinMe systems.
 
BTW, why doesn't the project code show all the variables that it shows for XP and Vista?

That is becase windows 98 did no support security as we know it tday. So you do need to fudge it a bit. I would use the Local Settings folder and create your appdatapath there. Find ou which parameter gave you that and us that for your Win 98 systems.

Back to non-network.  I'm trying my just for kicks install and run on the old Windows 98 machine I hauled out of the storeroom.  Okay with Setup.  It ran through, including something new - a direction to restart the computer Probably because of the AutoOSUpdater).  However, when I ran the app I got a Path Not Found Error (76) in my first-run code.
 
I'm guessing the problem is related to the generation of the AppDataPath from your project code.  To research I installed the project code and ran it.  Instead of the usual list of all the constants I got the following in a small window:
 
Randem SystemsDATAPATHCODE
 
Local SettingsTemp
 
and the OK button.
 
What's happening?  My purpose other than testing the install on W98 was to determine the AppDataPath on W98.  I'm also interested in WinMe (which may be the same).  I want to include these in the app's User Guide so users know where there data is.

Because of the added protection on Vista you may not be able to install in or share certain locations without going thru a lot of trouble. To the user (client) the location is immaterial but to the installer on the server it is important.

it's just where you install the files on the server that may change.
 
Do you mean the data files?  If so, why may their location change?

Correction - I was thinking about data files not the app.  The sharename can be Program FilesGHM for the app install.

No, you don't have to include a different share name for each OS. That part will remain the same, it's just where you install the files on the server that may change. The UNC will stay exactly the same, if you share it correctly...
 
PLEASE...