[RESOLVED] Vista Error (MSWINSCK.OCX)

Ok so i have this rather large program that im using, im working on making it Vista compatible.. There was a tun of work to do but im almost finished with it finally!

The only problem left is this. When the user starts the program, it starts up a splash screen, that form connects to a server app i have on a sever computer, and it checks for updates. If the version of the program is less then the version of the EXE file on the server, then it will run the patcher application as well as the updater app on the server. The server will wait a few seconds then try to connect to the users computer, and it sends the entire EXE file, after the transfer, the patcher updates the EXE file, runs the new version of the program and closes itself.

The problem. Both the main app and the patcher use the Winsock control. There's several of them all over different forms. On the patcher app, there's only one.. But on vista computers, when the program tries to run the patcher app, it says this:

"Component ‘MSWINSCK.OCX’ or one of its dependencies not correctly registered: a file is missing or invalid"

I dont get this error on the comp with VB installed, but all other computers with vista, i get this.. They can not update! I dont get why this happens. That control does the exact same things on both apps. So they need to be registered the same, and on the main app it works just fine! And on XP machines it works just fine!

anybody have any ideas? Ive look around the net and they have said to do 2 things.. Remove and Reinstall the program, which ive done and it didnt work. And to reinstall the winsock control, with some packaged version or whatever from microsoft, ive done that and it didnt work either.

Is your pathcer / updater running with elevated admin permissions? If not it needs to be in order to register or install teh component.

Quote:

---

Originally Posted by RobDog888

Is your pathcer / updater running with elevated admin permissions? If not it needs to be in order to register or install teh component.

---

The patcher is installed with the main app when the program is installed.

BUT!!! I think i might be seeing what your saying! When the splash screen is up and its doing updates, it will download a new patcher if one is available, and i update it every now and then.

Is there a way to run it with admin privelages through code?

But the patcher is a secondary program so it will need to request elevation of its own process. You can do this with a manifest file.

http://vbforums.com/showthread.php?t=500666

Contains the file example.

k i'll give this a shot and let you know how it goes within the next week or so, i got a few extra things lined up, and i wont be working on it this weekend. So probably tomorrow hopefully!

Will this work in XP as well?

I dont believe so, I think the xml setting to request elevation is a Vista or Windows 6.0 and above feature only.

Whats the quickest way to combine my EXE file and my .Manifest file?

I remember running acrost a thread here before, and whatever program it was, i already had on my computer, and it combined the 2.. It was a little dos program, but i cant find that thread anymore. All the threads i found have a HUUUUUGE download, or the link doesnt work =(

You can do it all in VB if you want by adding the file to vbs resource addin with a particular tag that tells it its a manifest but I forget what the tags is right now. A search could bring that up. Otherwise if you want to use a program there is REssoiurce Hacker. I believe its freeware.

Ok i feel more and more stupid every day.. I dont understand this manifest file stuff at all...

I know the manifest file is XML, and it has to be injected into the EXE file somehow. Well i know it can be done through VB, i went through this website for an older program i made:

http://www.vbforums.com/showthread.p...=manifest+file

That site is for adding an XP theme, but something about it doesnt seem right, like the code you put into your program is strictly for adding the XP theme, and making your program request admin rights itself when running, will not work....

So yeah, now i feel stupid cuz ive spent the past few days trying to figure out how and its not working ::cry:

The menifest file needs to be of 4bit increments. So if its 46 bits in filesize then you need to add 2 more bits to it by adding a space character r such.

For testing dont embed it yet. Just give it the same name as the exe and place in the same directory as the exe. It should request admin permissions when run if you have the UAC on.

ok i searched again and found this thread
http://www.vbforums.com/showthread.php?t=482140

randem explains well how to get the info in there, and it works.. It embeds the manifest file into the exe file, it even shows the vista shield on the icon when i select it, but my issue remains.

I still get this error:
"Component ‘MSWINSCK.OCX’ or one of its dependencies not correctly registered: a file is missing or invalid"

But i also noticed something! I logged onto one of the computers on my account, my program was installed on another account. I tried to run the program that was installed on the other account, and i got the same error! Usually its only with the patcher part..

So i installed it on mine, and it works, but still not the patcher..

So now i know the installer does "something" that associates the files with the installed program, but it doesnt associate it with any other EXE files in the program? If the patcher had its own install program, it would work.. But thats kinda stupid to do in my opinion..

any more ideas? :eek2: :eek2: :eek2:

That is the same manifest file contents that are in my post from earlier.

You have to determine if you are linking to the same common controls version that your winsock is registered under as the registereed file may not be in the location that is was registered with.

how do i do that? Just open up each project in VB and make sure the controls in the patcher app are the same exact controls from the main app? then recompile it?

Is the patcher program started through the Main application ??

Via ShellExecute?

If so, then the Shelled program receives the same UAC elevation as your main program. So if your main program doesnt request admin level then your pathces runs with no admin level.

Well the manifest file links one version of Comctls but winsock is not part of it so any manifest file linking for comctls will not change anything. You will either need to unregister and reregister the ocx or try to add a new section in the manufest file to point to the correct location of the ocx control.

Quote:

---

Originally Posted by some1uk03

Is the patcher program started through the Main application ??

Via ShellExecute?

If so, then the Shelled program receives the same UAC elevation as your main program. So if your main program doesnt request admin level then your pathces runs with no admin level.

---

Yes its using the shell command to run the patcher. If the program is installed on the current account, the program runs fine but the patcher gets this error:
"Component ‘MSWINSCK.OCX’ or one of its dependencies not correctly registered: a file is missing or invalid"

If the program is run from an account it was not installed from, then even the main program will get that error and not run...

Quote:

---

Originally Posted by RobDog888

Well the manifest file links one version of Comctls but winsock is not part of it so any manifest file linking for comctls will not change anything. You will either need to unregister and reregister the ocx or try to add a new section in the manufest file to point to the correct location of the ocx control.

---

Aahjsdfa3h@%!$%!!!!!!!! Ok ..i..... im ..... im lost!!!!!!!! How do you do that? I know nothing about how these manifest files work... its a file full of senseless garble to me!

Ok lets back up for a second.

Locate your winsock.ocx control and make sure that its registered correctly and the location matches what the registry says is its location or manifest file is pointing to the correct file/version.

Then if so it may be a permissions issue which isnt allowing your app to access the location where the ocx is located.

Quote:

---

Originally Posted by RobDog888

Ok lets back up for a second.

Locate your winsock.ocx control and make sure that its registered correctly and the location matches what the registry says is its location or manifest file is pointing to the correct file/version.

Then if so it may be a permissions issue which isnt allowing your app to access the location where the ocx is located.

---

Ok there's something i dont understand at all.. Your saying the manifest file is pointing to the common controls earlier and i need to also make it point to mswinsck.ocx? Well.. where does it point to that? Here's the contents of the manifest file:

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity version="1.0.0.0"
        processorArchitecture="X86"
        name="EXENAME"
        type="win32"/>
<description>elevate execution level</description>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
        <requestedPrivileges>
            <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
        </requestedPrivileges>
      </security>
  </trustInfo>
</assembly>

---

Of course EXENAME is changed to the name of my EXE file, but what am i supposed to change or add? I dont see it pointing to any files other then my exe file!?

Ok, good you dont have the comctls in there, just security node.

Check your registry for the location of where your ocx is regisered to. What is the file location and the location it states is in the registry? You will need to search for it in the registry. If you have trouble finding it you can unregister it and reregister it like I previously suggested.

Every file location in the registry points to MSWINSCK.OCX at C:\Windows\System32\MSWINSCK.OCX

And thats exactly where its at... I re-registered it, and it didnt work.. I even downloaded this MSWinsock install package that installs all the necessary files for mswinsck.ocx to work, and puts in all the necessary registry entries and everything, and still... the patcher wont work, but the main program will...

It almost sounds like the original installation registered the Winsock control in a virtualized Registry location under HKCU.

By starting the "patcher" with ShellExecute (or ShellExecuteEx) instead of CreateProcess, it is subject to Vista's installer detection heuristics. If Vista thinks it is an installer it will run in an installer context, which bypasses vitualization. If the "patcher" has requested an executionLevel via a manifest it will bypass installer detection, but will also not be subject to virtualization.

The fix would not be to use CreateProcess, or this manifest won't help you.


Something like this must be going on if the Winsock control appears to be installed and registered, and the base program can use the Winsock control without a problem. Maybe checking the Registry with RegEdit elevated would help see what's happening?

Quote:

---

Originally Posted by dilettante

It almost sounds like the original installation registered the Winsock control in a virtualized Registry location under HKCU.

By starting the "patcher" with ShellExecute (or ShellExecuteEx) instead of CreateProcess, it is subject to Vista's installer detection heuristics. If Vista thinks it is an installer it will run in an installer context, which bypasses vitualization. If the "patcher" has requested an executionLevel via a manifest it will bypass installer detection, but will also not be subject to virtualization.

The fix would not be to use CreateProcess, or this manifest won't help you.


Something like this must be going on if the Winsock control appears to be installed and registered, and the base program can use the Winsock control without a problem. Maybe checking the Registry with RegEdit elevated would help see what's happening?

---

Ya lost me :eek: :eek:

BTW: You can skip the manifest by calling ShellExecute with the "runas" verb to request elevation.

Windows Vista for Developers – Part 4 – User Account Control

Quote:

---

Originally Posted by PMad

Ya lost me :eek: :eek:

---

For legacy applications (like a VB application that doesn't have a Vista Trust manifest element) Vista will jolly you along and do registry and filesystem virtualization. It will let you think you changed or added something to a protected location (like where components are normaly registered) but behind your back redirects you to some per-user location.

If your base application was installed as a legacy app, the Winsock control may have been registered in such a private place. However your patcher is probably detected as an installer (it can be as simple as the way the EXE is named) and so it will not see the virtualized location. Using a Trust Level manifest element will also prevent your patcher from seeing the private registration of the Winsock control.

Just running RegEdit (w/o elevating it) may fool you the same way.

Well, as you have already noticed, ive tried using a manifest file to run the patcher as admin, that didnt fix the problem. Ive made up my install packages a few different ways, didnt work.. Ive re-registered mswinsck.ocx on the computer, didnt work... Ive used different versions of MSWINSCK.OCX, didnt work.. Ive used an installer package for MSWINSCK.OCX, didnt work..

The weird thing is when the program is installed, it will ONLY work on the account its installed on (minus the patcher). If you change accounts and try to run the program, you get that error on the main program as well, but if you re-log back onto the account it was installed on, it works fine.. This is probably why you said it was registered under HKCU right? Please keep in mind, either of these 2 ways, the patcher still doesnt work..

Now on the computer VB6 is installed on, everything works just fine through code, and the installed program. Maybe that will help us identify where this problem is at?

Quote:

---

Originally Posted by dilettante

For legacy applications (like a VB application that doesn't have a Vista Trust manifest element) Vista will jolly you along and do registry and filesystem virtualization. It will let you think you changed or added something to a protected location (like where components are normaly registered) but behind your back redirects you to some per-user location.

If your base application was installed as a legacy app, the Winsock control may have been registered in such a private place. However your patcher is probably detected as an installer (it can be as simple as the way the EXE is named) and so it will not see the virtualized location. Using a Trust Level manifest element will also prevent your patcher from seeing the private registration of the Winsock control.

Just running RegEdit (w/o elevating it) may fool you the same way.

---

What do you suggest i do to solve this issue? Ive searched all over the internet and these forums, and there's no answer anywhere... Others have had the problem too, and still have not had their problems answered.

It seems clear that Vista has profiled your application as a legacy program. Probably your installer as a legacy installer as well. So, your hat in hand like a nice hobo, Vista doled out a bowl of soup hoping to keep you happy and then turned its back on you. ;)

The first question I'd have is what installer technology you used to install this with in the first place?

But something you can try in the meantime is to log on as the user it works for and uninstall your application entirely. Follow this by an elevated reinstall (right-click, run as admin). Then retest and at least see if the base application runs for all users.

Quote:

---

Originally Posted by dilettante

It seems clear that Vista has profiled your application as a legacy program. Probably your installer as a legacy installer as well. So, your hat in hand like a nice hobo, Vista doled out a bowl of soup hoping to keep you happy and then turned its back on you. ;)

The first question I'd have is what installer technology you used to install this with in the first place?

But something you can try in the meantime is to log on as the user it works for and uninstall your application entirely. Follow this by an elevated reinstall (right-click, run as admin). Then retest and at least see if the base application runs for all users.

---

I used Visual Studio Installer, not that great.. but seems to be the only one i can really understand haha, i'd like to use Inno, but the scripts are too complicated for me to take the time to sit down and figure them out.. I have to much to do, i'd rather not spend the time trying to figure it out...

I have already tried running the install as admin by right clicking and using Run As Administrator, but this didnt work. :eek2:

Im gonna try it again, its been awhile since ive tried it, some of my changes might make that work.

Ahh, there's the rub then!

If you mean VSI 1.1, it doesn't "know" how to make an "ALLUSERS" MSI by itself. Do you have Orca?

Quote:

---

Originally Posted by dilettante

Ahh, there's the rub then!

If you mean VSI 1.1, it doesn't "know" how to make an "ALLUSERS" MSI by itself. Do you have Orca?

---

Ahh! What the heck is Orca? It sounds familiar... Its another installer program? I'll look for it.. hopefully its easy to use!

Orca is a Microsoft utility for editing the database inside an MSI package. It's a pain to get, you need to install the platform SDK if you don't have it, then install Orca.msi found in the bin directory in the installed SDK.

Quick and dirty thing you can try:

1. Start an elevated command prompt.
2. Change CD to the folder with your MSI in it.
3. Type: msiexec /i yourpackage.msi ALLUSERS=2

I also have a script you could modify and use following each VSI build. Just paste this into Notepad, change the relative path to your MSI file in the OpenDatabase() line, and carefully save it as a .WSF file in your VSI project/solution folder. This one enables a per-user install by a non-admin user without elevation prompts at all.

To create an ALLUSERS admin installer just change it to add ALLUSERS set to 2 instead of the actions included here. It doesn't require Orca:

PUEditMSI.wsf

Code:

---

<job>
<!-- PUEditMSI.wsf

    The purpose of this script is to edit an MSI package's database
    after building it via Visual Studio Installer 1.1 to add or alter
    settings that VSI 1.1 does not support by itself.

    This script needs to be rerun after every VSI 1.1 build of the MSI
    package.

    This version is for the GetFileRS application, and makes sure that:

      o Word Count Summary has bit 3 set, and

      o TARGETDIR is in LocalAppDataFolder (Installer's name for
        CSIDL_LOCAL_APPDATA), and

      o ALLUSERS is null (doesn't exist).

    This allows installs of the application per-user w/o a UAC prompt
    under Vista.

    Note the confusing SQL here: there is a Table named Property that
    also has a primary key field named Property!
-->
<reference object="WindowsInstaller.Installer" />
<object id="Installer" progId="WindowsInstaller.Installer" />
<script language="VBScript">
Option Explicit

Const PID_WORDCOUNT = 15
Dim Database, SummaryInfo, View, Record, OldTarget, EndVar, NewTarget

Set Database = _
    Installer.OpenDatabase("Output\DISK_1\PUGetFileRS.msi", _
                          msiOpenDatabaseModeTransact)

Set SummaryInfo = Database.SummaryInformation(1)
With SummaryInfo
    .Property(PID_WORDCOUNT) = .Property(PID_WORDCOUNT) Or &H8&
    WScript.Echo "Word Count Summary now " & CStr(.Property(PID_WORDCOUNT))
    .Persist
End With

Set View = _
    Database.OpenView("SELECT Target FROM CustomAction" _
                    & " WHERE Action = 'DIR_CA_TARGETDIR'" _
                    & " AND Source = 'TARGETDIR'")
View.Execute
Set Record = View.Fetch

If Record Is Nothing Then
    WScript.Echo "Missing TARGETDIR action, aborting"
    View.Close
    WScript.Quit 1
Else
    OldTarget = Record.StringData(1)
    EndVar = InStr(OldTarget, "]") 'Char index of EndVar or 0.
    NewTarget = "[LocalAppDataFolder]" & Mid(OldTarget, EndVar + 1)
    Record.StringData(1) = NewTarget
    View.Modify msiViewModifyUpdate, Record
    WScript.Echo "Target was """ & OldTarget _
              & """ and is now """ & NewTarget & """"
End If
View.Close

Set View = _
    Database.OpenView("SELECT Property, Value FROM Property" _
                    & " WHERE Property = 'ALLUSERS'")
View.Execute
Set Record = View.Fetch

If Record Is Nothing Then
    WScript.Echo "ALLUSERS already omitted"
Else
    View.Modify msiViewModifyDelete, Record
    WScript.Echo "ALLUSERS deleted"
End If
View.Close

Database.Commit
</script>
</job>

---

Addendum:

Changed the script to change Target as well. VSI 1.1 can set it to several places, but not the one we need.

Tested fine. Non-admin Vista user installed, ran the app, and uninstalled with never one elevation prompt.

Just looked on my comp, i had the SDK installed already, i found the Orca.msi file and installed it..

Im still not sure how to use what you just provided for me?

I copy and paste that into notepad, change the 'OpenDatabase' line to reflect the current path of my MSI file, then save the notepad data into a file with an extension of .WSF into the folder my VSI Project is in? And then what? How do i integrate it into my MSI file?

After you create a fresh MSI file you run this script (just double-click it).

The alternative is to run Orca, open your MSI with it, open the Property table, and add a new row and set the Property column to ALLUSERS and the Value column to 2.

The script is easier (you have to do this every time you make a new MSI).

Quote:

---

Originally Posted by dilettante

After you create a fresh MSI file you run this script (just double-click it).

The alternative is to run Orca, open your MSI with it, open the Property table, and add a new row and set the Property column to ALLUSERS and the Value column to 2.

The script is easier (you have to do this every time you make a new MSI).

---

Ok, gonna give it a shot, i totally understand it with orca and the WSF file. I'll let you know in a few minutes if it worked or not.

VSI 1.1 can't be told to use an ALLUSERS value. No idea why not, but I think it was crippled intentionally as welfare for InstallShield, etc.

NONE of this will help with your patcher though. It will still need elevation one way or another (manifest or "runas")... unless it only writes to non-protected filesystem and registry locations.

Good luck!

Alot happening while I was gone. :thumb:

Itsthe Virtualization that is fooling the other user accounts from seeing winsock being registered on the system(s). This is what I was getting at when trying to determine where and if he could see the ocx being registered under.

Good analysis on detecting the all user installation wasnt being handled by the installer dilettante. :thumb:

I think this is turning out to be more of an installation issue so Thread Moved

Well, after adding the manifest file from RobDog888, and sticking in ALLUSERS with a value of 2 into the MSI file after being built, it works!

by the way, wow.. didnt know we even had an Application Deployment section haha

So should i test this and see if the manifest file RobDog888 suggested is necessary for this to work in vista? Or is it a definite must regardless?

Thanks. "Even a blind squirrel..." as they say. I thought this was a Winsock control usage issue myself.

I've been holding back on suggesting reg-free COM. I find it helps a lot in Vista. Of course his application probably targets OSs before WinXP as well anyway so it wouldn't apply.

Glad it's working!

You might keep the manifest if your patcher writes to Program Files. The ShellExecute with "runas" will probably give a pre-Vista user heartburn... they changed how it works in Vista from the earlier versions of Windows. Pre-Vista the Vista Trust stuff will be ignored as long as correctly formatted.

Quote:

---

Originally Posted by dilettante

Thanks. "Even a blind squirrel..." as they say. I thought this was a Winsock control usage issue myself.

I've been holding back on suggesting reg-free COM. I find it helps a lot in Vista. Of course his application probably targets OSs before WinXP as well anyway so it wouldn't apply.

---

This app was originally intended for XP only, no support for any older OS's.. Awhile after Vista came out, i decided i should make it vista compatible since eventually, everyone will have to move to vista... So thats where im at now, XP and Vista only, i dont care if it does or doesnt work on any other OS, the app is for this company i work for, and we only use XP and Vista :bigyello:

Quote:

---

Originally Posted by dilettante

Glad it's working!

You might keep the manifest if your patcher writes to Program Files. The ShellExecute with "runas" will probably give a pre-Vista user heartburn... they changed how it works in Vista from the earlier versions of Windows. Pre-Vista the Vista Trust stuff will be ignored as long as correctly formatted.

---

What ive done is create 2 install packages.. One for XP and one for Vista. The XP installer defaults the installation to Program Files, the Vista defaults the installation to the Users folder.

The program currently uses the Shell command to run the patcher (i shoulda called this updater, nothing is actually "patched"), should i modify the code to include this "runas" thing your talking about?

Using the runas verb with ShellExecute is just an alternative (for Vista) to using an elevation manifest.

If Users is fully read-write you don't even need the manifest, but I doubt that. Actually if users will be installing elevated you can just use Programs/Program Files for both XP and Vista as long as you move any writeable data files to a folder under CSIDL_COMMON_APPDATA:

Method 4: Install to a common per machine location

Quote:

---

Another method is to install just the non-executable game data to a subdirectory of SHGetFolderPath CSIDL_COMMON_APPDATA. This is a shared location for all users and can be modified by Standard User applications.

---

Ok this is getting my attention...

I went to your link and read the whole page, the SHGetFolderPath and CSIDL_COMMON_APPDATA things are interesting...

But a few issues, first.. I dont understand either of them... the SHGetFolderPath looks like some kinda API command in VB, and the CSIDL_COMMON_APPDATA looks like a path in the registry... but i dunno!!!

Also the SHGetFolderPath on that link doesnt work. Can you briefly explain how to use these? That link says by doing this, you can install the app to Program Files, and without even needing administrator privelages, you can update all the files necessary... Which is a big thing to me because before, when installing the program to Program Files under vista, i had to change the security settings for each user on the apps folder so that it could update the files, if i didnt do that... The program couldnt even modify the contents of its own files, or create anything... it was annoying!

SHGetFolderPath() and friends are for getting the paths to special folders (duh) and working with them. CSIDLs are how you describe which folder you're interested in.

You still need to install elevated into Programs, but the data can be elsewhere.

Have you looked at AppEx Class, Assists Vista Programming?

Quote:

---

Originally Posted by dilettante

SHGetFolderPath() and friends are for getting the paths to special folders (duh) and working with them. CSIDLs are how you describe which folder you're interested in.

You still need to install elevated into Programs, but the data can be elsewhere.

Have you looked at AppEx Class, Assists Vista Programming?

---

Ive used Environ("USERNAME") several times in this app and others to get the name of the user. Im sure thats different then the class your mentioning.

It seems like with vista, Microsoft made application deployment 10x more difficult!! It used to be easy, now there's a bunch of extra steps to take... its crazy! Maybe this is just for vb6? Does .NET have these issues?

So for my program, i have the main app, a patcher app, 2 folders with images and saved files from the app, then several different config files in the app's main directory, as well as 2 files in the windows directory. Using these things you mentioned, i'll be able to install my app, and modify all the saved files and config files in the apps folder and the windows folder without problems?

The problem with environment strings is they can be changed by users to any garbage they want. But basically they'll work.

Quote:

---

Using these things you mentioned, i'll be able to install my app, and modify all the saved files and config files in the apps folder and the windows folder without problems?

---

That might be asking a lot, but basically yes.

You might even be able to get VSI 1.1 to store those files in the right places during installation! If not, you'd need to install them into Programs and then on startup have your program check for them in the right location. If missing, copy them over from Programs.


BTW: Yes, .Net programmers have these same issues, which always gives me a warm chuckle since they start out feeling superior until their own programs hit the wall.

Quote:

---

Originally Posted by dilettante

You might even be able to get VSI 1.1 to store those files in the right places during installation! If not, you'd need to install them into Programs and then on startup have your program check for them in the right location. If missing, copy them over from Programs.

---

Thats exactly what my program already does. My program is a bidding program for a heating company. So there's a Proposals folder for the bids thats ever changing since new bids can be created, they can be deleted, or uploaded/downloaded from the server, there's an Images folder for the bids since they can have images attached to them, and they are printed off on page 1, so this is another ever changing folder.

In the main folder is a config file for products, presets, employees, spiffs, all kinds of things, and all the settings for the control panel (including password) are encrypted in a file in the windows folder. During install, there's a few files that have to be there, so they are included in the installation package. The rest of the files (including the files in the windows folder) are created if they dont exist when the user goes into a section where they would be used.

This is still possible with your method? It seems weird if they are since i had so many problems before! But some parts are starting to make sence.

It's not my method, Microsoft started promoting this around the time Win2K came out and was back-ported even to Win95. It's been part of "da rules" ever since but until Vista it wasn't enforced.

I'd think anything maintained for all users would go into CSIDL_COMMON_APPDATA while anything per-user should be placed into CSIDL_LOCAL_APPDATA. What's confusing?

I think the Windows folder is protected. Seems like you'd use CSIDL_COMMON_APPDATA instead.

Quote:

---

Originally Posted by dilettante

I'd think anything maintained for all users would go into CSIDL_COMMON_APPDATA while anything per-user should be placed into CSIDL_LOCAL_APPDATA. What's confusing?

---

Whats confusing is i dont know what CSIDL_COMMON_APPDATA and CSIDL_LOCAL_APPDATA is, or how to use it, or where, or anything.. Its like some weird word(s) thats just thrown in out of nowhere that im supposed to use... but ..... how? What is it? the CSIDL_COMMON_APPDATE, isnt that the common files folder inside program files? Or are you talking about a registry entry? Am i supposed to write some info about my app and the files i need to be able to modify into some section with that name into the registry so that i can access the files i need to modify in my programs folder or the common files folder or something? You see where my confusion is at?

Well you could just go get that sample project at the link I put up there a few posts ago.

It has a Class module in it to do this, and you could just drop it into your own projects. Most of the details are spelled out in comments.

You can also read CSIDL and SHGetFolderPath Function.

Don't bother with KNOWNFOLDERID, new for Vista. You want your program to work on XP too. Also don't worry too much about "deprecated" functions for the same reason.

Quote:

---

Originally Posted by dilettante

Well you could just go get that sample project at the link I put up there a few posts ago.

It has a Class module in it to do this, and you could just drop it into your own projects. Most of the details are spelled out in comments.

You can also read CSIDL and SHGetFolderPath Function.

Don't bother with KNOWNFOLDERID, new for Vista. You want your program to work on XP too. Also don't worry too much about "deprecated" functions for the same reason.

---

Ok i'll do that. Thanks for all your help! Im going to mark this thread resolved. If i have any more questions about this i'll make a new thread for it. Thanks RobDog888 and dilettante for all the help!