I would like to download a vb6 program to whomever requests it on the web. Is
there a standard control, or app that can be called to accomplish this. It
seems all downloads over the internet work similarly. A user requests the
download of something, specifies where to store it and finally if they want
to run the install on their computer. Where can I get this program?

thank you for any advise.

Err...so what...you want to create a setup program, or you want to duplicae
the functionality of downloading a file via and/or similiar to a web
browser?

Your request is a bit vague.  Please clarify.

Show quote Hide quote Yes initially I will use the VB6 setup function to create all the pieces
required for distribution. But I want to use the internet to distribute and
install the program on the requesters computer.  Can you point me to the
program to accomplish the internet download. 

jerryys

Show quoteHide quote

On 31/08/2010 03:31, jerryys wrote:

No special controls required.

Simply create an installer for your program (to ensure that all the
required dll's and other stuff get bundled up in there as well) and
upload this to a suitable web site.

The users' web browsers will do the rest when they navigate (follow a
hyperlink) to the installer.

Regards,
    Phill  W.

Show quote Hide quote How do I create an installer? And it sounds like the browser will request if
the user wants to save or run the program (install it) . I'm surprised its
not a std set of code on the Web site from which the user requests the
download to accomplish this task.
Are there any samples you can point me to.

jerryys

Use the Package and Deployment Wizard that came with VB. Search MSDN and
MSKB for that name. Another option is Inno Setup, which is free:

http://www.jrsoftware.org/isinfo.php
http://www.jrsoftware.org/iskb.php?vb

For this you need to make setup for your VB6 program. Setup can be made
using InnoSetup (its script based) or using ClickTeam installer which is
easy for new users, there are many more. You have to collect all files
required by your program and include in your setup. i recommand you download
Virtual PC 2007 and install windows in it so you can test your setup.


Show quoteHide quote

Show quote Hide quote Im more interested in the piece that actually sends the result of setup from
the server  web site to the requesting party. It seems that all of these web
sites that offer an application develop the code from scratch if I understand
you right.

jerryys

You need to make setup for you app first.
then you need to upload the setup file to your website using a FTP client
like FileZilla or WSFTP
then you need to make a html page with a link to that setup file.
user clicks the link and file will download.

Show quoteHide quote

Like the others have said, you just host your file on your web page server
and provide a link to it on the page. The user goes to your web page using
whatever browser he normally uses and he clicks the link on your page. Then
the user's browser takes over and pops up a standard download dialog,
typically with the buttons Open, Save and Cancel or Run, Save and Cancel, as
appropriate. It is the user's browser which displays that dialog. No code at
all in respect of the dialog is required at your end. If the file the link
points to is an executable file then the dialog will automatically provide
Run, Save and Cancel buttons.

I've never actually done this for a VB project myself because I don't ever
distribute stuff in that way, but I'm pretty sure that one way of doing it
would be to use the Package and Deployment Wizard to create a standard setup
package and then use something like Winzip to create a self extracting zip
file and set it so that it automatically runs the setup.exe file that is
part of your setup package as it unzips it. The actual Winzip self
extracting zip file that is produced is of course a single file that has an
..exe extension. So, as far as your web page is concerned, it actually hosts
the self extracting Winzip file, and that it what the link on your web page
points to. When someone goes to your web page and clicks the link then his
own browser will automatically display the download dialog with Run, Save
and Cancel buttons (it will automatically display Run rather than Open
because it is an executable file). If the user clicks "Save" then he can
save the single self extracting Winzip file to his desktop or wherever else
he wishes and deal with it later, and if he instead clicks the "Run" button
then his browser will download your self extracting Winzip file and
automatically run it, and the self extracting Winzip file, which you had set
to autorun the setup.exe file when you created it, will then go about its
business of unzipping the files and installing your VB app on his machine.

There are certainly many other ways of tackling this job using something
other than Winzip (perhaps something specifically designed for the job) and
those other methods might produce a much fancier and perhaps more flexible
user display in the process, but I'm pretty sure the above method would work
okay.

Mike

  It works well for me. But I use Power Archiver. WinZip is a bloated
waste of money unless one already owns it. PA is too, but the last
free version, 6.1.1, is still available online with an unrestricted
license. Also, 7-zip can make self executing zips (SFX). 7-Zip is
free. Typically an SFX will unpack to %TEMP% and run the EXE
file of one's choice. So the PDW package is put into the ZIP,
converted to SFX, and set to run setup.exe after unpacking.

To the OP:
  I've been using my own updated version of the PDW installer
for some time. It sounds you should use the regular PDW.
But test it on Vista/7 before distributing. And use the word
"setup" in the name of your download file so that people
installing will do it with admin rights. Most installers will need
admin rights on Vista/7. The PDW has an odd quirk whereby
it actually copies the setup files to %Windows% before starting
the install, so it probably needs admin rights in all cases.

On 9/1/2010 5:46 AM, Mayayana wrote:
Show quoteHide quoteIZArc is free, integrates with Windows File Explorer, has an intuitive
gui, and supports dozens of compression algorithms.
http://www.izarc.org/

I decided to give that a try. The first thing that
happened was that it tried to go online before even
showing a window. After a bit, having been blocked,
it started the install. Partway through it showed
this:

"This installer uses the OpenCandy network to recommend other software
you may find valuable during the installation of this software."

  'OpenCandy'. What an odd name for a sleazeball
operation. IzArc is adware and spyware, but there's
no indication of that until partway through the install.
The website implies that it's free with no strings.

On 9/1/2010 8:15 PM, Mayayana wrote:
Show quoteHide quoteI am using IZArc 3.81 so it's been a while since I downloaded or
installed it, but I never saw anything like what you described. To find
out if I see the same thing I did this:
1. load this page.
2. click the green "Download Now!" graphic to the right of
    IZArc version 4.1.2  01.07.2010 Windows 2000/XP/2003/Vista/7
3. this page loaded http://www.brothersoft.com/download-izarc-23348.html
4. The IZArc4.1.2.exe file downloaded, and I double-clicked on it.
5. I saw the IZArc install wizard splash screen and clicked the Next >
    button to perform the installation.
6. I saw this warning and decided not to continue, as it sounds like
    ehat you are seeing:
January 26, 2010

This installer uses the OpenCandy network to recommend other software
you may find valuable during the installation of this software.
OpenCandy collects *NON-personally identifiable* information about
this installation and the recommendation process.
Collection of this information ONLY occurs during this installation
and the recommendation process; in accordance with OpenCandy's
Privacy Policy, available at www.opencandy.com/privacy-policy

By clicking Back and Cancel twice the installation was halted and
nothing was installed.

I apologize for the trouble you had, I had no idea they had made a deal
with OpenCandy. I won't upgrade my version and will look for another zip
utility when it stops working.

Mike

Looks good to me, i mean this opencandy thingy.


Show quoteHide quote

  Yes, it sounds interesting from the point
of view of a shareware developer. But it's
rummaging around the Registry, working out
geo-location, and calling home with that info. --
all without asking for permission or even informing
the person installing software. I get very tired
of the disclaimers that talk about "no personally
identifiable information". It's not true and that's
not the point. If you return home to
find someone has broken into your house, should
you believe him when he says that he's just there
to survey your breakfast cereal choices? Even if
that's true...he broke into your house, and your
breakfast cereal is none of his business!

   I could imagine this kind of thing working if
it were not sneaky. Maybe have two downloads,
with one offering free downloads for other software.
Or maybe just ask permission during setup, before
trespassing on one's system. Unfortunately, the
stuff these things pedal is also usually undesirable
junk spyware, so they probably can't make it work
as a legitimate business.

  Maybe all is not lost. Knowing the last good version
I did a search and came up with this:

http://www.getfreewares.com/2009/03/izarc-381-build-1550.php

The second download link, from the GetFreeWares
server, delivered v. 3.81 build 1550. I've never
heard of "getfreewares.com", but I ran the installer
and didn't find anything odd or unexpected. It seems
to be legitimate.

Mayayana wrote :
I install IZArc on *lots* of machines.

It works great in x64, where older versions of WinZip (licensed prior
to being bought by Corel?) don't.

Highly recommended.

Yeah, it's checking to see if you have the latest release.  I kinda
like that, because I don't have to bother checking myself when building
a new system.

Graceful degradation. <g>

I don't like that, either, but it's very easy to uncheck whatever the
recommendation du jour is, and proceed with the intended install.  You
never get any more of that crap from that point onward.

It is.  Unless you call "paying attention" a string.

On 9/2/2010 11:32 AM, Karl E. Peterson wrote:
<snip>
Great, I didn't know it let you install IZArc without OpenCandy. IZArc
is a very well done program.

Mike S explained on 9/2/2010 :
Show quoteHide quoteAfaik, OpenCandy is just an engine of some sort, that the install
queries and then prompts you with the result.  I guess it's like an
advertising thing.  The author probably gets a cut for every install
that gets pushed.  I can't begrudge a guy that, when he's putting his
own software out for anyone to use for free.

  It's an added part of the installer that checks your
Registry, geo-locates, then calls home to get a list
of recommended programs based on that. You don't
have to install anything, and it looks like the install
will still work if it's blocked. Other companies pay to
have their software advertised during the install.
That's sleazy spyware in my book. I don't want to
encourage that sort of behavior. But it's true that
you can circumvent it if you have a decent firewall.

On 8/30/2010 7:31 PM, jerryys wrote:
I would consider making the installer with the Package and Deployment
Wizard that comes with VB6, then zipping all of the files it creates
into one zip file, and letting the user download that zip file.

Show quote Hide quote But how does the user download this file and automatically has the option to
install the application? Sample code would help.

jerryys

Show quoteHide quote

  Do you have a website? You post the file to your
website and put a link on your webpage. If you don't
know how to do all of that then you have some research
to do. :)
  Creating the installer package/file is one step. Putting
it online is a different operation.

    The idea of installing
from online is different. Some things like Microsoft
service packs may install from online. You don't want to
mess with that. It would need to run from your website
server. It's unnecessary. And it's intrusive. Just make
your installer and put it on your website for download.

....Haven't you downloaded software before? If not then
just try downloading and installing some small program
to see how it works.

Thanks to everyone who helped. I can now apply these procedures.

jerryys


Show quoteHide quote

=?Utf-8?B?amVycnl5cw==?= <jerr***@discussions.microsoft.com> wrote:
What's wrong with using the package deployment wizard / installer that comes
with VB 6.0?  It has several options and works very well.  Just remember to
include the non-obvious files in your distribution script that you may need
such as maybe database files, resource files, etc.

On 02/09/2010 20:12, David Kaye wrote:
Many things.
A Brief entry from: http://hashvb.earlsoft.co.uk/Setups
It's also not really vista aware, it predates even Windows 2000 and the
standards have come a very long way...

   You just have to learn how it works. It's entirely
customizable because the source code is available
and it's VB. How much more customizable could it get?

  That makes it sound quirky and temperamental.
It gets stuck in a reboot loop when people don't
know what they're shipping and end up packaging
system files that are newer than those that came
with Windows versions having system file protection.
PDW reboots to replace files, SFP (now WFP) then
puts back the old versions without informing the
end-user. (A Windows bug, really. Not a PDW problem.)
So PDW reboots again to update the file. Etc.
  There's no excuse for not knowing what files you
need to ship, regardless of what installer you use.
That's not the fault of the PDW.

**No system files are supposed to be shipped for any
system with SFP/WFP. The only approved way to get
them is via service pack.**

  If they're being shipped to accomodate Win9x they
should be shipped as the Win9x version.

   Another misleading statement. It requires a reboot
on Win 95/98 if no VB6 software has ever been installed.
In other words, VB6 is, for all practical purposes,
dependency-free.

   If you don't want to bother with the PDW that's
perfectly understandable. It really should be updated
a bit, even if just to replace that old-fashioned splash
screen... And not everyone wants to take that trouble.
But if you don't really understand how the PDW works
then you shouldn't just throw out misinformation about
it being broken. You're just contributing to widespread
misconceptions.

  In short, the PDW is only broken for people who
don't take the trouble to understand what they're shipping.

.. . . and for girls who have a yearning to be a man ;-)

I keep re-reading it, but.... it must be a Brit joke. :)

On Mon, 6 Sep 2010 10:47:58 -0400, "Mayayana"
<mayayana@invalid.nospam> wrote:

Show quoteHide quoteWhich presents a seque to what IMHO is another advantage of getting to
know Setup1 (warts and all).

Many developers approach software installs as some kind of magic, when
if fact it is a very straight-forward process. I'm not in favor of
developers using script engines (such as InstallShield or Inno) right
off the bat. They make creating packages a little easier, but still
maintain the illusion of some black-box processing. It is useful to
spend a little time with Setup1 and running it in the IDE to just see
what is involved in installing software.

I still use P&D for most of my own installs. Recommend it for most
small shops. However, as it has been pointed out MSI has definite
advantages in larger shops and enterprise environments (where I too
use it), and if one is planning to go into the shrink-wrap business
InstallShield or one of the other more featured products are
definitely useful.

But amazingly P&D, for all its faults, just keeps chugging along. <bg>

-ralph

   I was actually talking to someone last week who's
in charge of installers for a large, well-known company.
She uses IS, but is in the process of converting custom
IS script actions to MSI actions, to take advantage of
MSI integration. That *does* seem to be very important
to corporate admins who have to do things like apply a
patch to software installs on hundreds of machines...
or do a rollback... or run an audit of what's installed.
All of that can be done with simple scripts, regardless of
installer used, but with MSI it's more systematic.

  Fortunately for me....or maybe unfortunately, come
to think of it....I don't get many corporate admins who
want to buy several hundred copies of anything. :)

You can do it with PsExec, and PDW if you wish, but you have to modify it so
it doesn't show a GUI, otherwise your setup program seems to hang, and the
user have to end the process. Example:

psexec \\* -c -d -f -i MySetup.exe /MySetupSilentOption

This would install your software on all computers on a domain at once.

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

On Mon, 6 Sep 2010 18:03:04 -0400, "Mayayana"
<mayayana@invalid.nospam> wrote:

Show quoteHide quoteLet us not forget that still today, in a vast number of small and
medium shops (and an embarressing large number for IT purest),
sneaker-net is still the preferred method for installing and upgrading
software. <bg>

-ralph

On 06/09/2010 15:47, Mayayana wrote:
Yeah, it was a mess when I last looked at it ~10 years ago so gave up :)

Show quoteHide quoteWeren't these the files installed by the bootstrapper before it got to
the ones we'd selected?
Even so, it was in the list of files included by default.

By two step, it is the bootstrapper to install some things, then the
main setup to install the rest. (Yes, I also dislike other setups that
have to install an installer first)

That applies to everything, it's just MUCH easier to get a working
install out the box with other products.

The fact it needs extra effort and there is nothing telling them that
the install is 10+ years old and really should be updated is a
significant problem IMO.

But, as I've always said, if you have it working the way you want, then
fine :)
My page is aimed at people that don't have anything yet and are looking
for a quick and easy, supported and up to date method.

  I understood that. What I was saying was that that
doesn't apply anymore. You're right that the PDW adds
the runtime files by default, so people have to know
enough to remove them from the list. But they don't
need to be shipped. I've been using the PDW without
even any setup.exe for years. I probably get 50-150
downloads per day of some kind of VB software. (Almost
all of it free, unfortunately. :) Yet it's been many years
since anyone has written to complain that they have an
error message about MSVBVM60.DLL. If someone did,
I'd direct them to a download link.

  To my mind there's no excuse for not knowing the full
story on every file shipped, regardless of what the PDW
or anything else suggests. Every once in a while there's
a bad problem. There was one a few years back with
MSVCRT.DLL, for instance. I don't remember the details.
I think it was something about a mistakenly versioned v.7
that would replace the version on XP and wreak havoc.
And there have been problems with RichEdit versions. One
such problem has been planned around in the PDW code.
It was written to prevent replacing RichEdit v.1 on NT4.
....Etc.

   Do other products take care of that sort of thing?
Does Inno maintain a list of what files/versions can
go to what Windows versions? That would be a nice
feature. Though I'm not sure I really like the idea. It implies
that people who have no idea what they're doing could
pack an installer that would work fine on my PC. :)

On 07/09/2010 14:40, Mayayana wrote:
I agree, that won't stop people trying though :)

It has a list of unsafe files (mainly OS specific DLLs), but then it
doesn't try and install them by default anyway :)

I'm happy to accept that PDW works fine, if you rewrite the setup,
remove a load of the auto included files, remove the bootstrapper, etc...

I also say that Inno works fine. :p

Maybe that is a bad thing if it allows people with no idea what they're
doing to create them.
This is why we always point out best practices in the Inno newsgroups,
but it is still down to them what they actually do...

On 8/30/2010 10:31 PM, jerryys wrote:
I have another question concerning not the same issue, but the same
subject matter (PDW).

Does anyone know how to get PDW to check for an existing file if the
install is an update, and then not install the file on the user's
computer if it already exists?

This would be good for those who wish to create an updated version of
something but not want to overwrite an existing database which would be
included for those who have not installed this package before?  Or
prevent overwriting setup files used in the software, but needed to be
included in fresh installs?

I think this would be a good thing to know for anyone new to using PDW
as well as those who have used in in the past like me.  I haven't really
delved into the setup1 vb program to see what's happening in there, but
thought there may be a way to do this during wizard operations.

Thanks

Show quote Hide quote Nothing in the wizard itself for this.  The functionality is in the Setup1
program. If both files have version information, then the version numbers
are compared.  The distributed file is only copied if the version number
indicates it's more recent than the existing file. If there is no version
information for either file, then date stamps are compared. Other rules
apply if one file has version information and the other does not. Right
off-hand, I don't recall exactly what the "rules" are for that situation. I
think that's when you will always get an OK to overwrite prompt. What you
really need to do is open Setup1.vbp in VB6 and just start exploring the
source code.

Files are only installed if they're a later version, so you
could just update with earlier versions if that works. If you don't
have a versioned file you could edit the function CopySection
in setup1. The loop in
that function extracts files, gets the extension, etc. One of
the operations is to call SourceFileIsNewer, to see whether
a file being installed is newer than the existing copy. If the
file being installed has a later version than the existing it gets
installed. If there's no version number it checks the date. **

  You could replace the call to SourceFileIsNewer with a
FileExists function that would change the operation to
"if the file doesn't exist then install it".

   If you want to continue using the original setup1 without
further edits, just do that edit on a copy of the project and
compile it. Put it into a folder labelled "updater" or some
such. Put the original setup1 into a folder named "installer".
Then just swap out the copy in
C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\
before running the wizard.

** Note that the original code in setup1 contains an error.
The code in SourceFileIsNewer compares versions. If
there is no version it compares dates. The date check
is backward. The original code reads:

If sFile.varDate < datDest Then

It should read:

If sFile.varDate > datDest Then

So if you want to update some files based on version,
but not update other files if a copy already exists, then
you need to be aware of the date check. I actually
rewrote that whole thing for my own purposes. The MS version
of SourceFileIsNewer is confusing. It uses a custom enum
of newer/older/same when it could have just used a boolean
value. It also adds in confusing names.
  For instance the constants fcNewer
and fcOlder are used. But then there's a double negative
switcheroo back in the CopySection function. fcNewer
becomes owNo and fcOlder becomes owYes! The meaning
goes from "is it newer?" to "should it be overwritten". It's
no wonder, in light of that, that the original authors got it
mixed up. (This explanation may sound confusing now, but
will be relevant if you edit setup1.)

Lockup Continues
Why doesn't this work (sendmessage)
Radio Button Bug?
file and folder permissions
Google is the new AntiChrist
Re: VB5 Runtime on Windows 7
PAUL CLEMENT (MVP) IS A TROLL
Lockup
Create Shortcut
Showing/Using Sort arrows on vb6 listviews?