"Mike" wrote

| Was lost linkage to some unspecified module it needed.
| I quit trying to install it on a different drive.
|
You could try running Procmon to see what it's trying to
access. I haven't yet tried running VS6 even on Win7.
As I understand it, one has to create a dummy msjava.dll,
but that's all I know.

| The remaining problem is that, when I run the deployment
| wizard, it hangs at "Loading Package Types".
| Task manager says it's not responding, but it uses 25% of the processor.
| No obvious disk activity.
|

Sounds like some kind of loop. I don't know where
it gets that list vb6dep.ini seems to be the only
settings file. But if you already have a PDM file in
the project folder you could try removing that to
start over.
I can't remember ever having any problems with
PDW, but I guess it's not so surprising on Win10.
VB6/VS6 is complex and it's not Win6+ -aware.

One important thing, though, is not to ship
the runtimes. That will make your install hang.

| I discovered another interesting anomaly.
| My clock program stores data in a text file in the program directory.
| Windows 10 seamlessly moves that file to my users directory so it can be
| written. Stumped me for a while when editing the file didn't affect the
| program. Now that I know what to look for...
|

Ick! Virtualization. I didn't know that it's even worse
in Win10 than in Vista/7. For what it's worth, I came up
with an approach that works for all versions without
inviting calamity from Windows virtualization or other
file restriction problems. I mentioned it above. I create
subfolders in the program folder and store things like
settings files there. (You'd want to use App Data if
you target a multi-user scenario, but I don't write
anything like that myself. I'm assuming SOHo user
who owns their own computer.)

The PDW rewrite I linked includes a function to
remove all restrictions from the created subfolders.
That could also be run as a separate EXE if you don't
want to fiddle with setup1.exe.

I find that since Vista, the biggest problem, by far,
with the actual install and with designing software is
file restrictions. Your clock program is a good example.
They didn't design it properly. As it turns out, the
virtualization problem is both a help and a hndarnce,
as usual. But the real fault is with the people who
wrote the software. (Unless the installer pre-dates
Vista.)

Also, one other note: You may know about this, but
just in case: 32-bit can't run in a 64-bit process and
vice versa. It's not a problem for a 32-bit EXE, but
ActiveX DLLs should be written as Ax EXEs in the future.

It's the same thing except that an Ax EXE runs in a
separate process. So it's OK for 64-bit. It's slightly
slower due to marshalling, but usually not an issue.
The only exception would be where only your software
will access the DLL.

Similarly, shell extensions are no longer possible
for 64-bit. That's the one thing I miss. I use an Explorer
Bar I wrote myself, that loads in folder windows, but it
can't be used on 64-bit because shell extensions run
in the Explorer process.
On the other hand, I'm not sure how much there is
to miss at this point. Many of the things I've written --
mime filters, BHO, browser extensions, property pages,
explorer bars -- are being phased out as MS locks
down the system.