MAtkins

New Member
Joined
Jul 26, 2010
Messages
2
It seems no matter what I do, Windows 7, obviously my superior, won't let me.

I wrote an app in VB6 for a client. It writes data to text files and creates pdf files.
If it runs on Windows 7 (and apparently Vista), it throws a 'file/path access error' and won't complete the job. This is a really 'simple' application.

I just downloaded a C# project from CodeProject.com. I can't open it in my IDE. Guess why - 'file/path access error'.

Is there any way to write a software program that writes files (to its own directory) that runs in Windows 7? Realize, this application is supposed to be sold en-mass to customers so going through procedures to alter the operating system won't help.

I sure hope the next version of Windows isn't like this. It's an absolutely miserable operating system just because of the way overkill security.
 


Solution
Ok, this is kinda new to me, so forgive me if I don't explain this well enough... But I've been through it in my own code ( Ansi-C) and there are a couple of things you have to do.

First you need to work up a manifest for your program and include it in your program resources. Mine generally look like this...

Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32"
                    name="AutoLogon"
                    version="1.0.0.0"
                    processorArchitecture="X86" />
  <description>
    Auto logon tool
  </description>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32"...
Ok, this is kinda new to me, so forgive me if I don't explain this well enough... But I've been through it in my own code ( Ansi-C) and there are a couple of things you have to do.

First you need to work up a manifest for your program and include it in your program resources. Mine generally look like this...

Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32"
                    name="AutoLogon"
                    version="1.0.0.0"
                    processorArchitecture="X86" />
  <description>
    Auto logon tool
  </description>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32"
                        name="Microsoft.Windows.Common-Controls"
                        version="6.0.0.0"
                        processorArchitecture="X86"
                        publicKeyToken="6595b64144ccf1df"
                        language="*" />
    </dependentAssembly>
  </dependency>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel  level="asInvoker" 
                                  uiAccess="false" /> 
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

This will get you past the UAC with most program code. For more details check MSDN for "Manifests" and "Side by Side" information.

However it is generally considered bad form to write data into a program's own folder in Win7. Better you should have it create a folder in either the Private or Shared user areas and stuff your files in there. It will put files in a sub-folder of your program files folder (eg. c:\Program Files\MyCode\MyData ) for an admin level user (meaning setting your programs to "Run as Administrator") but it's just a lot easier to make a folder in the open areas of the tree.

Usually I put a slot in the settings so a user can pick/create their own work folder and default it to %userprofile%\Program_Name This of course takes away all premise for grumbling about lost files... :)

Programming for Vista was a nightmare... Win7 is a little better... My own current project is using registry, local file (temp folder) storage and networking... It's also Unicode... you wouldn't believe the juggling act it's putting me through to get this all working. I cobbled together a prelim version in XP in under 3 weeks. The Win7 version is 6 months and counting... Since it's likely the finished product will be used on everything from win 2000 to present (most likely XP since it's multimedia) every system call has to be vetted for version compatibility and there are several things I simply can't do. It's actually very discouraging.

I'm with you... Win8 had better address these problems if the shareware/freeware market that made MS what it is is not to be destroyed.
 


Solution
Back
Top