VB6 weirdness on W7
in [Visual Basic]
|
Prev: Find Addin
Next: How to XOR hex values ?
From: Nobody on 7 Apr 2010 12:10 If this is in-house software, then one solution is to always right click your app, and use "Run as administrator". Another solution is to add the following to your Inno script(assuming that the INI file is in the same folder as the EXE, otherwise change as needed): [Dirs] Name: {app}; Permissions: authusers-full What you are seeing with Notepad vs. other software is file system redirection. Some programs have manifest so they are not redirected, but would get access denied errors if you don't have write permissions, while in others Windows silently redirects to another file, usually in a location like this: C:\Users\<UsedID>\AppData\Local\VirtualStore\Program Files\MyApp\config.ini The [Dirs] entry above would change the permissions so your app would work without having to use "Run as administrator". But this solution is not suitable in general for use because it introduces a security hole by making the EXE modifiable. So when a regular user go to a malicious web site and the computer gets infected, the damage is limited, however, because the EXE is now modifiable, an administrator who logs in later and runs your app, the virus can do more damage and could spread to the rest of the network. So it's better to fix your app. One quick way to fix an app is change the INI file location to a writeable location, such as per user location. So if you have code like this: inifile = App.Path & "\config.ini" Change it to: inifile = Environ("APPDATA") & "\MyApp\config.ini" On Error Resume Next MkDir Environ("APPDATA") & "\MyApp" This is not the most optimal code, but it's suitable for in-house use. If you want an optimal solution, use SHGetSpecialFolderLocation() or SHGetFolderLocation() with constant CSIDL_APPDATA. "SteveC" <admlcl(a)yahoo.com> wrote in message news:999b5eed-2db7-4297-8c9c-b6d2f96f1bfe(a)z6g2000yqz.googlegroups.com... new info,when the programme starts it loads a text file into a dropdown combo,I found out that if I edit that text file in MS note pad or directly in the programme, it saves fine,it I edit it in my preferred txt editor Crimson Editor then I get the problem although I can find no stray characters.and once again it worked OK in XP and I have made no changes since moving to W7. Not related to this problem but causing headaches anyway.I have a small machinist related programme that I sell a few copies now and then that when installed on W7 the usual way causes and error.I use Inno setup,always have and if the setup file is just clicked and run in the normal way when the programme starts I get an error, "error5 Invalid procedure call or argument",however if I right click the setup file and run as administrator then everything works as it should.I have changed the setup as suggested for W7,but not really being a programmer I don't know what to look for.This as far as I know is the way to put the programme on W7, regular click setup works on every other version of windows. SteveC On Apr 6, 4:54 am, "Phill W." <p-.-a-.-w-a-r...@-o-p-e-n-.-a-c-.-u-k> wrote: > On 05/04/2010 19:59, SteveC wrote: > > > I'm currently running it on W7 pro and periodically if will not save > > the file.I used it last week and it worked fine.This morning it failed > > to save the file.No errors,at least no VB errors,just the message > > box warning I put in on exit if I fail to save the file. > > If the program failed every time, I'd suspect either a coding problem or > something big in the environment, like UAC. Because it only breaks > sometimes, I'd start looking at "intervention by person or processes > unknown". > > Do you always save to the /same/ file? > Could another process have "grabbed hold" of it? MS Word is a old hand > at doing this; open even a text file in Word and nothing can update it > (certainly /used/ to be the case anyway). It was "great fun" when some > analyst opened up your server log file to have a look and all your > logging just "stopped" 'til they clear off for lunch! > > > I get the feeling that it is ignoring the sub that is that save file > > code, because that sub also indexes the packing index number and that > > doesn't change. > > Does it do the file save first? > Is so and the save is failing, that might be why the indexing doesn't > get done either. > > > I have made no changes to the programme since it last worked, and made > > no changes to the computer. The only thing I can think of is MS update > > broke something again. > > Always a possibility but updates usually break the "outlying" bits of VB > applications, the ActiveX Controls that we use but that aren't part of > the VB product itself (and, therefore, that Our Friends in Redmond don't > give a damn about). If your program is "pure" VB, without any external > controls (which would be rare) then this shouldn't be an issue. > > HTH, > Phill W.
From: SteveC on 7 Apr 2010 13:59 On Apr 7, 9:10 am, "Nobody" <nob...(a)nobody.com> wrote: > If this is in-house software, then one solution is to always right click > your app, and use "Run as administrator". Another solution is to add the > following to your Inno script(assuming that the INI file is in the same > folder as the EXE, otherwise change as needed): The problem seems to arise with the install,If you run the install as administrator then the programme runs as it should,doesn't need to be run as admin. > > [Dirs] > Name: {app}; Permissions: authusers-full I have this in the inno script. > > What you are seeing with Notepad vs. other software is file system > redirection. Some programs have manifest so they are not redirected, but > would get access denied errors if you don't have write permissions, while in > others Windows silently redirects to another file, usually in a location > like this: > > C:\Users\<UsedID>\AppData\Local\VirtualStore\Program Files\MyApp\config.ini > > The [Dirs] entry above would change the permissions so your app would work > without having to use "Run as administrator". But this solution is not > suitable in general for use because it introduces a security hole by making > the EXE modifiable. So when a regular user go to a malicious web site and > the computer gets infected, the damage is limited, however, because the EXE > is now modifiable, an administrator who logs in later and runs your app, the > virus can do more damage and could spread to the rest of the network. So > it's better to fix your app. One quick way to fix an app is change the INI > file location to a writeable location, such as per user location. So if you > have code like this: > > inifile = App.Path & "\config.ini" > > Change it to: > > inifile = Environ("APPDATA") & "\MyApp\config.ini" > On Error Resume Next > MkDir Environ("APPDATA") & "\MyApp" > > This is not the most optimal code, but it's suitable for in-house use. If > you want an optimal solution, use SHGetSpecialFolderLocation() or > SHGetFolderLocation() with constant CSIDL_APPDATA. > > "SteveC" <adm...(a)yahoo.com> wrote in message > > news:999b5eed-2db7-4297-8c9c-b6d2f96f1bfe(a)z6g2000yqz.googlegroups.com... > new info,when the programme starts it loads a text file into a > dropdown combo,I found out that if I edit that text file in MS note > pad or directly in the programme, it saves fine,it I edit it in my > preferred txt editor Crimson Editor then I get the problem although I > can find no stray characters.and once again it worked OK in XP and I > have made no changes since moving to W7. > Not related to this problem but causing headaches anyway.I have a > small machinist related programme that I sell a few copies now and > then that when installed on W7 the usual way causes and error.I use > Inno setup,always have and if the setup file is just clicked and run > in the normal way when the programme starts I get an error, "error5 > Invalid procedure call or argument",however if I right click the setup > file and run as administrator then everything works as it should.I > have changed the setup as suggested for W7,but not really being a > programmer I don't know what to look for.This as far as I know is the > way to put the programme on W7, regular click setup works on every > other version of windows. > SteveC > > On Apr 6, 4:54 am, "Phill W." <p-.-a-.-w-a-r...@-o-p-e-n-.-a-c-.-u-k> > wrote: > > > > > On 05/04/2010 19:59, SteveC wrote: > > > > I'm currently running it on W7 pro and periodically if will not save > > > the file.I used it last week and it worked fine.This morning it failed > > > to save the file.No errors,at least no VB errors,just the message > > > box warning I put in on exit if I fail to save the file. > > > If the program failed every time, I'd suspect either a coding problem or > > something big in the environment, like UAC. Because it only breaks > > sometimes, I'd start looking at "intervention by person or processes > > unknown". > > > Do you always save to the /same/ file? > > Could another process have "grabbed hold" of it? MS Word is a old hand > > at doing this; open even a text file in Word and nothing can update it > > (certainly /used/ to be the case anyway). It was "great fun" when some > > analyst opened up your server log file to have a look and all your > > logging just "stopped" 'til they clear off for lunch! > > > > I get the feeling that it is ignoring the sub that is that save file > > > code, because that sub also indexes the packing index number and that > > > doesn't change. > > > Does it do the file save first? > > Is so and the save is failing, that might be why the indexing doesn't > > get done either. > > > > I have made no changes to the programme since it last worked, and made > > > no changes to the computer. The only thing I can think of is MS update > > > broke something again. > > > Always a possibility but updates usually break the "outlying" bits of VB > > applications, the ActiveX Controls that we use but that aren't part of > > the VB product itself (and, therefore, that Our Friends in Redmond don't > > give a damn about). If your program is "pure" VB, without any external > > controls (which would be rare) then this shouldn't be an issue. > > > HTH, > > Phill W.
From: Nobody on 7 Apr 2010 14:14
Inno by default runs your app unelevated when you just double click it on Explorer. If you use "Run as Admin" to run the installer, then Inno runs your app elevated. "runascurrentuser" flag always run the entry elevated. "runasoriginaluser" flag will run the entry elevated based on how the user started the setup. If the user right clicked the setup file, and selected "Run as Administrator", then it will run elevated because the original user now was already elevated. If not(like double clicking on Explorer), the entry is NOT elevated. So this is elevated/not elevated issue. "SteveC" <admlcl(a)yahoo.com> wrote in message news:fd19ad1a-fca7-4b18-b6ba-fc4f302baa5e(a)g30g2000yqc.googlegroups.com... On Apr 7, 9:10 am, "Nobody" <nob...(a)nobody.com> wrote: > If this is in-house software, then one solution is to always right click > your app, and use "Run as administrator". Another solution is to add the > following to your Inno script(assuming that the INI file is in the same > folder as the EXE, otherwise change as needed): The problem seems to arise with the install,If you run the install as administrator then the programme runs as it should,doesn't need to be run as admin. > > [Dirs] > Name: {app}; Permissions: authusers-full I have this in the inno script. > > What you are seeing with Notepad vs. other software is file system > redirection. Some programs have manifest so they are not redirected, but > would get access denied errors if you don't have write permissions, while > in > others Windows silently redirects to another file, usually in a location > like this: > > C:\Users\<UsedID>\AppData\Local\VirtualStore\Program > Files\MyApp\config.ini > > The [Dirs] entry above would change the permissions so your app would work > without having to use "Run as administrator". But this solution is not > suitable in general for use because it introduces a security hole by > making > the EXE modifiable. So when a regular user go to a malicious web site and > the computer gets infected, the damage is limited, however, because the > EXE > is now modifiable, an administrator who logs in later and runs your app, > the > virus can do more damage and could spread to the rest of the network. So > it's better to fix your app. One quick way to fix an app is change the INI > file location to a writeable location, such as per user location. So if > you > have code like this: > > inifile = App.Path & "\config.ini" > > Change it to: > > inifile = Environ("APPDATA") & "\MyApp\config.ini" > On Error Resume Next > MkDir Environ("APPDATA") & "\MyApp" > > This is not the most optimal code, but it's suitable for in-house use. If > you want an optimal solution, use SHGetSpecialFolderLocation() or > SHGetFolderLocation() with constant CSIDL_APPDATA. > > "SteveC" <adm...(a)yahoo.com> wrote in message > > news:999b5eed-2db7-4297-8c9c-b6d2f96f1bfe(a)z6g2000yqz.googlegroups.com... > new info,when the programme starts it loads a text file into a > dropdown combo,I found out that if I edit that text file in MS note > pad or directly in the programme, it saves fine,it I edit it in my > preferred txt editor Crimson Editor then I get the problem although I > can find no stray characters.and once again it worked OK in XP and I > have made no changes since moving to W7. > Not related to this problem but causing headaches anyway.I have a > small machinist related programme that I sell a few copies now and > then that when installed on W7 the usual way causes and error.I use > Inno setup,always have and if the setup file is just clicked and run > in the normal way when the programme starts I get an error, "error5 > Invalid procedure call or argument",however if I right click the setup > file and run as administrator then everything works as it should.I > have changed the setup as suggested for W7,but not really being a > programmer I don't know what to look for.This as far as I know is the > way to put the programme on W7, regular click setup works on every > other version of windows. > SteveC > > On Apr 6, 4:54 am, "Phill W." <p-.-a-.-w-a-r...@-o-p-e-n-.-a-c-.-u-k> > wrote: > > > > > On 05/04/2010 19:59, SteveC wrote: > > > > I'm currently running it on W7 pro and periodically if will not save > > > the file.I used it last week and it worked fine.This morning it failed > > > to save the file.No errors,at least no VB errors,just the message > > > box warning I put in on exit if I fail to save the file. > > > If the program failed every time, I'd suspect either a coding problem or > > something big in the environment, like UAC. Because it only breaks > > sometimes, I'd start looking at "intervention by person or processes > > unknown". > > > Do you always save to the /same/ file? > > Could another process have "grabbed hold" of it? MS Word is a old hand > > at doing this; open even a text file in Word and nothing can update it > > (certainly /used/ to be the case anyway). It was "great fun" when some > > analyst opened up your server log file to have a look and all your > > logging just "stopped" 'til they clear off for lunch! > > > > I get the feeling that it is ignoring the sub that is that save file > > > code, because that sub also indexes the packing index number and that > > > doesn't change. > > > Does it do the file save first? > > Is so and the save is failing, that might be why the indexing doesn't > > get done either. > > > > I have made no changes to the programme since it last worked, and made > > > no changes to the computer. The only thing I can think of is MS update > > > broke something again. > > > Always a possibility but updates usually break the "outlying" bits of VB > > applications, the ActiveX Controls that we use but that aren't part of > > the VB product itself (and, therefore, that Our Friends in Redmond don't > > give a damn about). If your program is "pure" VB, without any external > > controls (which would be rare) then this shouldn't be an issue. > > > HTH, > > Phill W. |