VB6 using Write #1, (UnitCount

Question

I have a legacy VB6 system which uses the expression

Write #1, (UnitCount

to write a text file. (UnitCount is the first a several short integers that are written.)

This works well under XP but does not produce the text file under Vista and Windows 8. No error is reported.

Does anyone know how to fix this?

Also - the VB6 application is installed in C:/Program Files/IronDuke

and the text file is intended to be written here as well (i.e. in the current directory).

I am aware of the closing bracket. I only included a section of the statement.

Answer 1

Your application is being treated as legacy (not Vista aware) and so files you write to protected locations are being virtualized (not "isolated") instead of causing a security violation exception. A filesystem VirtualStore exists in each user's profile path.

It is perfectly possible for VB6 to embed an application manifest, though it will not generate one for you. You simply create the manifest file separately, then include it as a Custom resource with Type #24 and Id #1 and it will be compiled right in.

One caveat is that the manifest file should be UTF-8 XML padded to an even multiple of 4 bytes. If padding is required you can add spaces at the end. You can save this from Notepad as ANSI since generally only the 7-bit ASCII character subset is used and this avoids the risk of a UTF-8 BOM, which you do not want Notepad to write.

There are even simple ways to bypass WOW64 redirection when required, though there isn't a good reason to do so.

But instead you might find it far easier to either modify your Start Menu shortcut or create a new one if the program is indeed writing this file to its current directory. Just set the shortcut's current directory ("Start in") to some legaly writeable location such as your Documents directory, some directory on the D: drive, the Public special folder, etc.

Answer 2

The file is actually created, you just can't find it back. It is stored in isolated storage.

This is an appcompat feature in modern Windows versions, starting at Vista. Programs are no longer allowed to write to c:\program files. Or c:\program files (x86), the directory you'd write to on a 64-bit operating system. UAC protects these directories from malware and well-intended but dangerous programs, the program must acquire elevated rights by displaying the UAC prompt to let the user know that it is going to make major changes that might affect his machine.

Since your VB6 EXE file will look like an ancient program to Windows that is not UAC aware, a very accurate guess, it is going to automatically redirect the file to isolated storage to allow your program to execute properly. You'll have no trouble reading the file back either. But of course is not what you actually want to accomplish.

Getting your program to display that UAC elevation prompt is a bit tricky, VB6 was not designed to embed a manifest in the EXE file. Manifests didn't exist 15 years ago. You'll need to create a file named yourapp.exe.manifest file in the same directory as your yourapp.exe file. Use a text editor that can write utf-8 encoded files (not VB6) and make it look like this:

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>
</asmv1:assembly>

Do note that you still have a serious problem on a 64-bit operating system, you'll end up writing to c:\program files (x86) instead of c:\program files. There's no simple fix for that. Do consider looking for modern tooling that are better suited to modern operating systems, VB.NET will certainly give you a lot less trouble here.