Hello,

I am a VB programmer testing out my apps in Windows 7.  I am a XP guy
and have not really used Vista or 7.

I am trying to update a text file actually an INI file.  The program
does not generate any error messages but when I open the INI file it
has not been updated.  I also cannot update the file with Notepad.
When I try to save the file it wants me to do a 'save as' and when I
do a Save and it asks me if I want to overwrite the file I get a
'access denied'.  So it is not my VB app but more something with
Windows 7.

I am an advanced user with XP but like I said new to 7.  I installed
my app via my original setup.exe which creates a folder in C:\.  I am
guessing it is a permissions issue but this type of problem would not
have happened with XP.

thanks, David

I think you can change the rights on the C:\ folderpath to allow any user
r/w access (try Sharing\AdvancedProperties, etc.), or simply run your
application as Administrator.

Dick

Right click the exe and select "Run as administrator". Being logged in as
administrator means nothing in Vista, Windows 7, and W2k8, except that you
don't get prompted for credentials when you select "Run as administrator".
Many folders are now protected, such as "c:\Program Files" and "c:\", so
that normal users cannot write.

Show quoteHide quote

Sort of what I said.  I think you can "unprotect" these manually, though.

I have a similar problem with tmpfile() (admittedly, this is Visual C++). I
can't write to C:\, yet tmpfile() seems to init the temporary directory with
_P_tmpdir, which is defined to be "\\" (the root). So tmp files don't work at
all, unless I run everything as Administrator.

This did happen after a machine (not sure if it was Win7) crash. I don't
really like setting C:\ open like that, but it seems the stdlib library
forces me to?

Ruud

Show quoteHide quote

Show quote Hide quote The problem would occur with XP as well, if permissions were set the same,
but they usually weren't. By default, a user cannot change any files in the
Program Files subfolders (and many others), which is exactly the place that
you or I would normally put INI files. Changing a folder in the system drive
root (C:\) is /really/ a no-no.

The best solution is to select a location that you DO have permissions to
write to. An alternate is to run the program as an admin, and while that
seems sometimes necessary, for something this simple, it would not be.
Others will post the correct locations for such things. I, for INI and
similar usage, have the program create a file here, and save the INI there:

c:\Documents and Settings\All Users\Application Data\MyProgram\

This saves the INI in a single location no matter what user is using it. If
you need the INI in a per user location, you can use the User's Application
Data area instead.

As I said, there are lots of new and recommended areas to save files (both
configuration and data) to in Vista, and someone else will point you to the
proper links to those. Some seem good and logical; others, not so much. But
what you are experiencing is expected behavior, and you should concentrate
on doing what is allowed, rather than circumventing what is prevented.

Show quote Hide quote It'd mostly likely happen in XP too if you ran your app under a standard user account instead of an admin account.

Vista and Windows 7 don't change all the rules....they just now enforce rules that have existed in Windows for years.  For example,
in Vista and Win7, even if you're an admin, *most* apps aren't run with admin privileges.  They are run with the privileges of a
standard user even when logged on as an admin. Therefore, you should be writing your programs to function properly when run under a
standard user account.

In most cases, if your app will run under a standard user account in WinXP, it will work fine in Vista and Windows 7.

Thanks to everyone for all the suggestions; they were very helpful.

It does not really matter where I install the app.  The app is running
on a standalone PC basically that only has 1 user and the app is
'global' I guess.

Since I have not used Vista or 7 this whole security process is
someone new to me.  I tried googling but could not really find useful
info.  It seems like most stuff related to Windows 7 are user
interface related.  If you have any suggestion on Windows 7 websites I
would appreciate it.  One thing that would be good is something that
explains the conversion from \documents and settings\ to whatever
paradigm 7 uses.  If nothing else your comments will allow me enter
better search phrases in google.

Basically in my app I have string variables that point to a relative
path for whatever file I am looking for.  It does not matter where the
app (main folder) is installed.  The main folder could be on my
desktop (not that I want it to be) or in 'program files' or wherever.

-Main folder
  -app folder (3 exes)
  -config folder (ini and text files)
  -misc folder (misc files I keep)
-Data folder

I had thought Windows 7 wanted users to be standard users.  When I
installed 7 and created my user account I assumed that it was a
'standard' user and not an admin account and I thought somewhere
during the installation it would ask me about setting up an
administrator account and/or admin password.  Then when I created a
new admin account it did not ask me for a password and then set my
account as a regular user.  I went back to add a password to my admin
account.

Sorry if this posting is not 'VB' specific.

thanks again, David

You haven't hard-coded these, have you? If you did, your app WILL blow up under Vista/Win7. You should be using
SHGetSpecialFolderPath to obtain them.

Will any files in the config or misc folders need modified? If so, these folders should not be subfolders under your application
folder.  Reason is that by default, even admins most likely won't have write privileges to these folders. They only will if UAC is
turned off or the app is specifically run as administrator (this is done by the user right-clicking the EXE or its shortcut and
choosing As Administrator, and then they will be asked by Windows if this is OK).

It does.  So does Vista.  That's why even admins are essentially standard users.

It sounds to me like what you need to do is play around in Vista or Win7 for a little while. If you can't do that, then test your
app under a WinXP standard user account. If it runs OK in that, chances are it will also run OK in Vista and Win7 (as long as you're
not doing anything else you shouldn't be, like hard-coding paths to Documents and Settings folders).

I got quite a bit of suggestions so excuse me if I ask a dumb
question.

As a standard user I can create a folder from the C: drive.  If I
right click in Windows Explorer there is an option New folder although
no other options like text document.  Then within that folder I can
right click and select New Text Document or other doc types.  However,
if I go to my original folder I am having problems with I can only
create a New Folder.  However, I created a second folder at the same
level that does allow me to create different folder types.  I am not
sure I understand what is happening here.

David

There's no such thing as "different folder types," even though XP and later
would like you to believe there are. When you tell Windows that a folder
contains specific types of files (images, for example), Windows just adds a
special file in that folder indicating your preference and Explorer displays
things differently. The folder is still just a plain old folder, though.

Jeff,

I misspoke (or mistyped).  I did not mean 'different folder type'.  I
don't have 7 running right now so I can't recreate it exactly.  I
meant to say that I could create a folder within another folder.  But
basically the point of that last post was that I guess I don't
understand the rights issues for a standard user.  As a standard user
I can create folders (and files) off of the root drive.  Like I have
said previously it does not matter where the app is installed I just
put it there so I would not have to navigate to the 'program files'
folder during my initial testing.
Apparently my install program which was created using Visual Studio
2005 apparently had an affect.  Because if I create the folders and
copy the files to different directories everything works properly in
the sense that the files I need to write to are written to.

That being said I was having problems (registering dlls) installing
the app the first time as an administrator.

I am use to running XP as an administrator since most recommendations
say that running as a standard user (in XP) is very limiting so that
is why I have never had to use it.  I guess with Vista and 7 I need to
figure out which folders I do not have access to or where I should
place my apps.

   You seem to be in the wrong group. While the
permission issues are specific to Windows, your
installer is specific to .Net.

  VB and VB.Net are entirely different things, even
though MS has begun calling VB.Net just "VB".

  Microsoft dropped ".Net" from the name "VB.Net" as
part of their marketing strategy to sell .Net to VB developers.
Adding to that confusion, VB.Net has been named with several
versioning systems. There is .Net v. 1, 1.1, 2 and 3. There is .Net
2005 and .Net 2008. And sometimes the VB.Net versions
are referred to as VB7, VB8 and VB9, even though VB.Net is
not a continuation of VB6! These days, anything other than
VB5 or VB6 is probably VB.Net.

  You need to be aware of the difference between "the two VBs"
when looking for newsgroups. The same applies when searching
for sample code. VB and VB.Net code can look very similar in
some cases, but code in one system is not applicable to the other.

They are radically different programming systems. VB is a COM-
centric system for creating compiled software. .Net is a Java
clone that runs on top of a "virtual machine", the .Net Framework.
VB does not use the .Net objects. VB.Net is not directly COM
compatible. The only thing in common between the two is a visual
similarity in the language syntax.

  Try one of these groups, or you can also look
for installer-specific .Net groups:

microsoft.public.dotnet.general
microsoft.public.dotnet.languages.vb
microsoft.public.vsnet.general

(Note that the .Net groups have "dotnet" or "vsnet"
in their names.)

  Since (I think) .Net uses the Windows Installer
system you might also find help here:

microsoft.public.platformsdk.msi

Mayayana,

I did not know at the moment that I posted this question what
direction this conversation was going to go but this discussion has
somewhat morphed into a question for a Windows 7 group.  The apps
themselves are VB6.  I used Visual Studio 2005 to create an
installer.  The installer for 2005 has more features and/or
functionality than VB6 installers.

I did not intend for this post to get too involved but it has.  Like I
have said in previous posts I need to learn how Windows 7 works.
Using XP as an administrator you have complete access to the hard
drive except for certain areas (like My Documents) that set certain
security attributes.  I need to understand how Windows7 does this.

Even when I used my VB6 setup.exe (created with Visual Studio 6.0
installer/deployment thingee) and logged in as the Administrator I was
having problems with the dependent files (OCXs and DLLs).  So I just
need to figure it out.

I also need to figure out if I maybe I want to be logged in as
administrator on the PC that is running the app.  It is an industrial
computer that is not connected to the internet and from time to time
the apps are changed when someone with a USB memory stick copies over
a new EXE or they may want to run the EXE without 'installing' in a
different folder.

I am not asking any questions these were just comments.

David

Mayayana,

I know the difference between VB6 and .Net.  I have posted a lot of
postings to both newsgroups and I usually get responses that apply.
However, there are times when people post a question they think is one
thing and turns out to be related to something else.  And there have
been quite a bit of people wanting to participate in this discussion.

And like I said previously if I had known the nature of my problem I
would have put it in a different group.

David :)

Your posting was fine as far as I'm concerned.
I wasn't meaning to chase you off. I just saw the
part about the 2005 installer -- and you hadn't
mentioned VB6 specifically -- so I guessed you
were using .Net. A lot of .Net people end up here
not knowing the difference between the two. It can
get confusing for everyone.

  The issue of permissions of Vista/7 comes up
periodically. It's also confusing. :) As I mentioned
in my earlier post, the admin on Vista/7 is not
really an admin. It's a fake admin who has only
the opportunity to "elevate" permissions. The real
admin, like on XP, is the admin account. You can also
turn any fake admin account (anyone who is "in
the administrators group") into a real admin
account with a run command that takes effect on next
reboot and lasts until it's reversed. See here:

http://www.computerperformance.co.uk/vista/vista_administrator_activate.htm

  It's a lot like recent Linux versions, where root isn't
really root and there's an extra layer of obfuscation
required for "power users" to access the real root,
often called the "superuser".

You can find the official docs by searching for
UAC (user account control) and virtualization on
Vista. But it's rather convoluted. What it all comes
down to is that you can change permissions during
install (as I mentioned in my earlier post) but if you
don't do that, and you want all users to have full
access to a file, then it must go into the all users
documents folder. A normal user cannot access program
files subfolders or even all users app data folders
without changes in permissions. (I haven't tested the
exact extent of fake admin rights. It seems to be
that a fake admin is basically a normal user who gets
a permission prompt providing the option to "click their
way to permission" when attempting a restricted action
(if they enable UAC prompts). The difference being that a
normal user gets no option. They're just blocked.


Show quoteHide quote

A slight clarification to all that:

* The status one has on a new PC with Vista/7,
or after installing Windows with Vista/7, is that
of "fake admin".

* If you include a manifest with your program,
requesting admin rights, then fake admins will
get a prompt allowing them to approve their own
actions (i.e. "elevate").

* If a fake admin right-clicks and selects "Run
as Administrator" they can also elevate that way.

* A fake admin can also elevate permanently
with the method I linked to above. One advantage
to that is that you don't have to use a password
as a fake admin (or as a fake admin made real)
but the real admin is not allowed to not have a
password.

This issue came up in the scripting group because
in practice there are further limitations for a fake
admin. For instance, an HTA has no "Run as admin."
on the context menu. A drag/drop operation like
dropping a file onto a script or EXE provides no
opportunity to switch to admin mode. Etc.

   So for yourself there can be serious limitations
in using a non-elevated fake admin account. (Personally
I keep over a dozen drag/drop scripts on my desktop
for various utility purposes. I couldn't use them on
Vista/7 under a normal fake admin account.)

  For end-users, you can't assume people have turned
their fake admins into real admins. (The method for that
is semi-secret, after all.) So in that case you need
to decide whether to use a manifest and/or change
some permissions during install and/or restrict your
software's activity to things that a normal user is
allowed to do.

I target mainly stand-alone PCs myself and
have done some experimenting with Win7. I
also use INIs for program settings. You didn't
mention what installer you're using, but this
could be of interest:

www.jsware.net/jsware/vbcode.php5#set12

  It's a rebuild of the VB Package and Deployment
wizard installer, with some updates and with the
setup.exe dependency eliminated. I also added a class
for changing permissions. The way I've been doing it
is that the installer checks for NTFS filesystem.
If it is NTFS then the install window shows a
message explaining that the private program subfolders
for settings and program operations will be set with
full permission for all users, and that if desired, those
permissions can be changed after install. I then create
folders to store settings and temp files, set permissions
on them, and keep my program operations within those
folders. So far, in tests on Win7, it seems to work
well. People are only limited by the permission they have
for the files they want to work with, and I can store
machine-wide settings. At the same time, the person
installing has been informed and can override my install
design if they want to.

  For non-NTFS I do the same thing, but with no message
shown and no permissions to set. (The issue isn't really
Vista/7. It's NTFS/admin. settings. XP, by default, used
to install on FAT32, so permissions were irrelevant. With
XP the original user is also an admin. With Vista/7 there's
only an NTFS option and the original user is a "fake admin."
unless they choose to change that or run as the admin
account.

Show quoteHide quote

I need a Class 101 on threading in VB6
Off Topic But ... Related
Re: Multithreading
Walkthrough Instruction Error
vb memory layout
VB6 Rich Textbox control (vertical alignment of text)
Ghost Form
Displaying forms
direction finding with bing
Passing Structure (Type)