"Mike" wrote

| Historically, one such change was the change from
| VB6 to dotnet.
|
| You are stuck in the past, as am I, with VB6.

I see what you mean. That's an interesting issue.
Right now, VB6 and VC6 are the most widely supported
products of all. .Net was never big and still isn't. Like
Java, it's big on corporate back-ends for quickie
programming. But also like Java, it never made much
sense on Windows. It's slow and requires a monstrously
bloated runtime. And each runtime has restrictions.

That problem was why they stopped at v. 2 for awhile,
allowing later versions of VS.Net to target the v. 2 runtime.
DotNetters were frustrated with trying to sneak 1/2 GB
of slop past people who thought they were installing a
small utility program.

.Net was originally intended for "web apps". The
successor to ActiveX in IE. When web apps didn't
happen, MS pretended .Net was for Desktop, too.

http://web.archive.org/web/201011121...eliverspr.mspx

Then they tried to build Windows with it, which failed
miserably. (Longhorn.) By their own description, .Net
was far too bloated and slow to be handled by any
then-current hardware.

To this day, the only .Net software I have is the applet
for my display chip. and it takes forever to load. I
occasionally see something that wants .Net, but it
just isn't worth it in my mind to install all that bloat.
There's always a non-.Net option. And .Net usually
indicates the same problem as early VB: That the
programmer probably doesn't really know what they're
doing.

These days MS are pushing the Metro trinkets because
they get a cut. .Net is being repurposed to write what
are essentially little more than HTA webpage apps. Good
luck and good riddance. They have no market for that junk.
No one needs a Facebook or Uber app, or a flashlight
app, or an app to put kitty ears on your girlfriend's photo,
on a desktop.

But through all of that, the API for compiled software
has been dependable. If you stick with basic VB and
Windows API you can target any Windows version with
no dependencies. There's not as much commercial market
for software as there once was, but the Win95 API is
still supported. Anything that was ever made official is still
supported, with very few exceptions. For instance, in
Vista/7 with XP compat mode, GetVersionEx will lie and
tell your software you're on XP! So you have to use other
ways to find the OS version. But that kind of thing is rare.

If you target later it's even easier. For instance, I had
a Google maps program that used my own low-level
winsock code to talk to the server. It works on Win98+.
Later I decided to use winhttp. Much easier. It only
works on XP+, but that's almost everyone these days.
Each Windows version adds some conveniences.

| What isn't working is the package deployment wizard that lets me install
| the program on another computer without resident VB6.
| Got any advice on fixing that?
|

You didn't say what the problem is. A simple
EXE should work fine on any other machine,
depending on dependencies.

As for the PDW itself, see he

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

The PDW just figures out what the package needs.
Then it has setup.exe to kick off the install. That was
needed in Win9x times because the runtime was not
pre-installed. So setup.exe would do the runtime
install and then start setup1.exe. Setup1.exe is written
entirely in VB6 and the project is included in the Wizards
folder (or somewhere in that tree.)

The link is to an updated setup1.exe. Setup.exe
is no longer needed and causes problems because
Vista+ won't let you install system files. So it tries
to install them, reboots, then fails and starts all over
again. But none of that is relevant any longer. The
runtime has been pre-installed since WinME.

So I rewrote setup1.exe. I cleaned out a lot of
muck and added some things, like the ability
to make a Quick Launch icon, customize the setup
window, set folder permissions, etc. If you name
your final setup with "setup", as in AcmeEditor2setup.exe,
then Windows will assume it needs admin rights. You
can then set up folders with no restrictions to prevent
problems later.
File restrictions are probably the most common
problem these days. Example: You try to put program
settings in the program folder, to satisfy the portable
app craze. But then the software doesn't have permission
to write to its own settings file. The way I do it now
is to set no restrictions on a temp subfolder, if necessary,
and a settings subfolder. Then I keep all operations
within those subfolders. Safe and functional. No
fiddling with the app data catacombs. No risking that
windows will block an operation. At the same time, no
executable at risk of corruption because only data is in
those subfolders.

You can send email if you want. I'm happy to help
if I can. Email is in the download. But it won't get through
unless you have real email. No spyware, webmail crap.
Also, the VB6 newsgroup is still active.