|
How to d'load an EXE from the Net?
From experience, a lot of people have a hard time with going to the Downloads section of a web site, click on an EXE, save the EXE somewhere on their hard-disk, and launching it. But then, I guess I'm not the only one to have experienced the issue of where the heck did IE save the EXE, so I can understand why non-techies would have a difficult time with this whole procedure.
So... I was wondering if it would be possible to download a file by giving the URL to it in the Start > Run... dialog?
I tried just putting a URL (eg. http://acme.com/app.exe), but it launches the default browser... which is precisely what we'd like to avoid, since the "Save File" dialog is just too damn hard to use for most people.
FWIW, neither "copy \\www.acme.com\app.exe" ("The network path was not found.") nor "copy www.acme.com\app.exe" ("The system cannot find the path specified") work.
Too bad Windows doesn't ship with wge :-)
Thank you
FredF
Monday, February 2, 2004
Make the file available via FTP and then you can use a bunch of different automated ways to get the file.
pds
Monday, February 2, 2004
I had thought of this, but if downloading and running an EXE through IE proves to be a problem for a bunch of people... I doubt having them run FTP.EXE will be any easier :-)
FredF
Monday, February 2, 2004
How about wget? http://www.qtm.net/~twegscheid/wget.html
I have a batch file that CD's to my desktop and then downloads the given file using wget. Put the batch file in your PATH and you can fire it off from run box.
Jon Newton
Monday, February 2, 2004
Try a format like \\machinename\directorysharename\filename.exe
machinename can be a dotted IP address.
directorysharename is necessary (share a directory using windows explorer, not using IIS).
Christopher Wells
Monday, February 2, 2004
Can't you just tell them on the page to "open" instead of "save"?
Just me (Sir to you)
Monday, February 2, 2004
Jon Newton >> How about wget?
Precisely. The issue we need to solve, is how to download an EXE from the Net, using a more foolproof solution than going through IE. So... asking people to go to a web page to download wget.exe gets us back to square one :-)
Christopher Wells >> Try a format like \\machinename\directorysharename\filename.exe
Won't do, as the EXE's are on a web server on the Net, not an intranet. Obviously, our ISP will not set up Samba and share the hard disk in CIFS/SMB.
>> Can't you just tell them on the page to "open" instead of "save"?
Been there, done that... For most people, it's just too complicated, hence my search for an easier alternative. Everybody can at least click on Start, Run... and type a command in the little window before clicking on OK.
FredF
Monday, February 2, 2004
May be,
_____________________________________________
Option Explicit
Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
Private Const SW_HIDE = 0
Private Sub Form_Load()
Call ShellExecute(hwnd, "Open", "http://acme.com/app.exe", vbNullString, vbNullString, vbHide)
End Sub
___________________________________________
Sathyaish Chakravarthy
Monday, February 2, 2004
Interesting. So the user can follow relatively obscure commands "In Start, look for "Run" a dialog will appear into which you wil have to type exactly this string of letters without the quotes (") ...", but they can not follow a simple "Click here, and when the dialog appears click the 'Open' button"?
I am not implying you are wrong. Hell, I have seen stranger things, but this is one I did not expect.
Just me (Sir to you)
Monday, February 2, 2004
Nope. Remember, we must download an EXE from scratch... so writing an EXE that must be downloaded by the customer in order to, er, download an EXE... ;-)
Too bad copy or xcopy are still NetBIOS apps. I'm beginning to think the easiest wouldn't be to ask prospects for an e-mail, and just ship a light, 50KB launcher as attachment. But then, we'll have to deal with their antivirus...
FredF
Monday, February 2, 2004
FTP.EXE can be scripted via simple text input files, so you can remove the hassle by telling your users to do the following:
Go to Start->Run, now type in "\\servername\getfile.BAT" and it runs
REM just in case-delete the file
DEL %TEMP%\YourNewFile.EXE
FTP.EXE <somescriptfile.txt
%TEMP%\YourNewFile.EXE
Which opens an FTP connection to your FTP host, gets the file, closes. Then, assuming you put the EXE file in your temp directory, it immediately runs the file.
Maybe I'm misreading the 'difficult' part of the Open/Save dialog box--but this resembles something you need, right?
pds
Monday, February 2, 2004
Just me (Sir to you) >> ... but they can not follow a simple "Click here, and when the dialog appears click the 'Open' button"?
Trust me. First, they have to figure out what the default directory is, which happens to be the last directory where IE saved a file because they'll to go there next using Windows Exploder so as to launch said EXE. So... to avoid their saving the EXE in some obscure location, say, deep inside "C:\Documents and Settings\", we ask them to go back to C:\ by clicking on "the little up arrow"...
Suffice it to say that our experience shows that it's be faster to just have them read a line to type in the Run... dialog. Maybe you have smarter users :-)
pds >> Go to Start->Run, now type in "\\servername\getfile.BAT" and it runs
Thx but unless I'm mistaken, the \\ syntax works if the remote server shares its hard disk with SMB/CIFS. This is a shared Unix on the Net, so this won't work, hence no way to download a batch file to automate an FTP collection.
I'm beginning to think sending a small, Internet-based installer is the way to go :-)
FredF
Monday, February 2, 2004
Just me (Sir to you) >> ... but they can not follow a simple "Click here, and when the dialog appears click the 'Open' button"?
"Trust me. First, they have to figure out what the default directory is, which happens to be the last directory where IE saved a file..."
I think you're missing the point here. When you click on a link for an exe, the first thing it asks is "Would you like to open or save it to your computer". The choices are [open] [save] and [cancel]. If you click [save] then you get the dialog box asking the user where they want the file saved. However, if they click [open], no question is asked; The file is downloaded (into the users cache) and then run automatically.
That's about as easy as you are going to get it.
Almost Anonymous
Monday, February 2, 2004
I guess if your installer isn't an EXE they need to download, you could be onto something =)
Konrad
Monday, February 2, 2004
FredF- When you click on a link that points to an exe, Internet Explorer pops up a dialog with 4 options- "open", "save", "cancel", and "more info". If you hit "open", it just downloads and runs it automatically- you don't specify where it's saved or anything like that. The behavior you are describing occurs when you hit "save". Not sure which version of IE your users are running, but I'm pretty sure this is how it has worked since 5.0 or so.
Ken
Monday, February 2, 2004
Almost Anonymous >> However, if they click [open], no question is asked; The file is downloaded (into the users cache) and then run automatically
... which isn't going to help us much, since we don't want this app to end up in IE's cache directory, but be saved in a known directory, eg. C:\MYAPP\ . Hence the use of Save over Open :-)
Konrad >>I guess if your installer isn't an EXE they need to download, you could be onto something =)
It has to be an EXE, but I'll make that a light launcher, like the one you get when you install eg. IE 6 : The launcher is just 400KB.. because it'll download 20MB worth of code :-)
FredF
Monday, February 2, 2004
Just out of curiosity, why don't you want the file to end up in IE's cache?
Ken
Monday, February 2, 2004
Sounds like you're trying to write a virus.
I work on an app that has about 1 million users and the problem you're describing is non-existent. Yes, there is an occasional question where they say they've "downloaded the app, now what?", but that happens only about once per month, tops.
The Ted
Monday, February 2, 2004
Ken >>Just out of curiosity, why don't you want the file to end up in IE's cache?
Because currently, our app doesn't have an auto-updater, so we ask our customers to download and replace newer versions of our EXEs. Hence the need to launch IE, click on an EXE, move to where our apps live eg. C:\MYAPP, and answer YES when prompted to overwrite
The Ted >> I work on an app that has about 1 million users and the problem you're describing is non-existent
OK, so we have the really stupid users... but somebody's got to catter to those two. Besides, they're very unlikely to move on to another software editor :-)
FredF
Monday, February 2, 2004
I have your solution... Stop trying to teach monkeys how to download exe files.
Jon Newton
Monday, February 2, 2004
Ok- in that case, can you write an installer packaged as a self-extracting exe? Then the user can just click "open", the installer gets downloaded and run from IE's cache and extracts your "myapp.exe" and overwrites the existing one. I think this is similar to what you propose, except instead of e-mailing it to them, they could run it from the browser.
Ken
Monday, February 2, 2004
"... which isn't going to help us much, since we don't want this app to end up in IE's cache directory, but be saved in a known directory, eg. C:\MYAPP\ . Hence the use of Save over Open :-)"
"It has to be an EXE, but I'll make that a light launcher, like the one you get when you install eg. IE 6 : The launcher is just 400KB.. because it'll download 20MB worth of code :-)"
It sounds like these two things together to solve you problem. Make the download a light exe, they click [open] to launch it, it downloads/installs the necessary files in the correct directory.
And even if you didn't do that. The exe could just be smart enough to realize it's not in C:\MYAPP\ and copy itself there. If your exe is an installer, the directory it's saved in is a moot point -- the installer will put the files in the correct place no matter where the installer exe is saved to.
Almost Anonymous
Monday, February 2, 2004
>can you write an installer packaged as a self-extracting exe? Then the user can just click "open", the installer gets downloaded and run from IE's cache and extracts your "myapp.exe" and overwrites the existing one
Good idea. Until then, we just uploaded new versions of our EXE's, but from now on, we could package them as NSIS installer instead. Thx for the idea :-)
FredF
Monday, February 2, 2004
AA- Great minds think alike!
Ken
Monday, February 2, 2004
"I have your solution... Stop trying to teach monkeys how to download exe files."
Exactly.
There was a time, long long ago, when I didn't know how to do things like download files. So what did I do?
*I LEARNED HOW TO DO IT*
There is simply no excuse, other than laziness, for a person not to take a few minutes and learn how to perform simple computer tasks.
Schlemeil
Monday, February 2, 2004
Off the original topic, but PLEASE don't install your application into C:\MYAPP (or similar). Please follow the recommended practices and install into an appropriately named subdirectory under the "Program Files" folder (which is often NOT named "Program Files" and may not always be on the C: drive). Use the relevant Windows API functions to determine the path to the "Program Files" directory, or use an installer package which does that for you.
Philip Dickerson
Monday, February 2, 2004
I was trying to help someone with a similar problem. I was trying to explain to them how to copy some files from a CD to a specific directory on their hard drive. This guy is a practicing dentist, so he's got a few years of education under his belt.
After nearly an hour of trying to explain it to him, in the simplest terms I know how, and having him stare back at me blankly, as if I was speaking some incomprehensible alien language, I finally said "you know what ... you're too f***ing stupid to be allowed near a computer".
I'm sorry folks, but it has to be said. This is not brain surgery. Using a computer is not all that difficult if you're willing to take a little initiative to learn some things.
I did it. You did it.
None of us was was born knowing how to do this stuff. We learned. In many (most) cases we took the initiative to teach oursleves. I'm fed up with stupid lazy people.
Don't know how to download an .exe? Tough Sh**.
NO SOUP FOR YOU!!!
Maytag Repairman
Monday, February 2, 2004
"PLEASE don't install your application into C:\MYAPP (or similar). Please follow the recommended practices..."
I agree ...But ...
1. If "Program Files" isn't called "Program Files" and is located somewhere other than "C:", then the person obviously did a lot of tinkering with the default installation settings and should know their way around enough to find the app.
2. The "recommended practice" is to install to "C:\Program Files\Company Name\Program Name" which is horrendously stupid. If the average person, even someone who is fairly "computer literate" goes looking for City Desk on their hard drive, are they going to know to look under "C:\Program Files\Fog Creek Software\"?
Nanotech
Monday, February 2, 2004
Schlemeil >>There is simply no excuse, other than laziness, for a person not to take a few minutes and learn how to perform simple computer tasks
I wish I had your customers :-)
Philip Dickerson >> Off the original topic, but PLEASE don't install your application into C:\MYAPP (or similar)
We do because experience shows that we get things done faster by having users open a DOS box and type commands (Windows Explorer is just too error-prone). Having all our files located in a 8-character directory at the root is a lot easier than messing with LFNs
Maytag Repairman >> Using a computer is not all that difficult if you're willing to take a little initiative to learn some things
www.techtales.com ;-)
Bottom line: By Sunday, I'll have a reliable routine to download and update our apps from within. No more messing with IE. Thanks everyone for the brainstorming session.
FredF
Monday, February 2, 2004
"We do because experience shows that we get things done faster by having users open a DOS box and type commands (Windows Explorer is just too error-prone). Having all our files located in a 8-character directory at the root is a lot easier than messing with LFNs"
Does this strike anyone as an alien world where the last 9 years of Windows never existed?
If your users have to open a DOS box and type commands there is something seriously wrong with the UI of your application (in that it seems to lack one). It seems this application never had a standard installer. I can't be sure on this one but I wonder if it even puts an icon in the start menu?!?
It seems the entire user experience for this application is completely backwards to what the normal windows experience is.
Almost Anonymous
Monday, February 2, 2004
>>Does this strike anyone as an alien world where the last 9 years of Windows never existed?
How much time did you ever spend doing support for regular, non-technical users? :-) I feel right at home when I read stuff at TechTales.
>> If your users have to open a DOS box and type commands there is something seriously wrong with the UI of your application
Yeah, yeah... Until now, we didn't provide a way to have the app auto-update, so users would just click and save the latest EXE from our download area on our site. Hence the need to save this file in the right directory overwriting the previous version. Instead, since IE's interface is so convulated, at times the EXE ends up on the Desktop, or deep inside "C:\Docs & Settings", or wherever the user last saved a file. Wonderful...
FredF
Monday, February 2, 2004
In response to Nanotech's reply to my off-topic post about the "Program Files" folder (and sorry if this getting too far off-topic):
'1. If "Program Files" isn't called "Program Files" and is located somewhere other than "C:", then the person obviously did a lot of tinkering with the default installation settings and should know their way around enough to find the app.'
Perhaps I should have explained a little more - "Program Files" is one of the localized names in Windows, so in most languages other than English, it is named something else - such as "Programme" (I think) in German Windows.
As for it being on the C: drive - it is less common now with larger hard drives, but a lot of system administrators for company systems used to have a C: drive for the operating system and move other folders such as the "Program Files" and "My Documents" folders to a second drive (D:). Some manufacturers of home PCs also used to do something similar. So, the "Program Files" folder may be on a drive other than C: even without the end-user being specifically aware of it. Also, some users consciously move the "Program Files" directory to a different drive (because it fits in better with their backup strategy or disk imaging strategy, for example) - in this case, it's bad manners for an application to install into a hard-coded "Program Files" folder on the C: drive.
' 2. The "recommended practice" is to install to "C:\Program Files\Company Name\Program Name" which is horrendously stupid. If the average person, even someone who is fairly "computer literate" goes looking for City Desk on their hard drive, are they going to know to look under "C:\Program Files\Fog Creek Software\"? '
Actually, the recommended practice is to install to "Program Files\Application Name" or to "Program Files\Suite Name\Application Name" (for a group of products).
Philip Dickerson
Monday, February 2, 2004
"How much time did you ever spend doing support for regular, non-technical users? :-) I feel right at home when I read stuff at TechTales."
Like most people around here, lots!
"Until now, we didn't provide a way to have the app auto-update, so users would just click and save the latest EXE from our download area on our site."
This is the first time you mentioned that this was to update the exe of an existing installed application (applying a patch). Doing the auto-update from inside your application is by far the best solution.
An alternative solution would be not have the bare application exe available for download! Rather package that into an installer that copies the file in the right place. A little compression might even make this a smaller download.
Almost Anonymous
Monday, February 2, 2004
"Does this strike anyone as an alien world where the last 9 years of Windows never existed? "
Yes it does, and if FredF was trying to pull these stunts on on my machines he'd be booted out on the first possible opportunity.
Just me (Sir to you)
Tuesday, February 3, 2004
Almost Anonymous >> Rather package that into an installer that copies the file in the right place
Nope, since having them download _anything_ is the issue I was trying to solve, be it a newer EXE, or an installer :-)
OK, I'll just write a generic update.exe, that takes the name of the EXE to download as input through COMMAND$, download the file through some secure way (WININET.DLL? URLMON.DLL? I understand INET.OCX is not reliable), kill the main EXE, replace it with the new version, launch the new EXE, and kill update.exe.
Thx everyone :-)
FredF
Tuesday, February 3, 2004
Another reason Program Files may be on drive D: is a dual-boot system. I had a computer that dual-booted Win95 (C:) and Win2K (D:). Removing that Win95 partition won't be an easy task because so much software that was installed in Win2K actually ended up on drive C:
A.T.
Tuesday, February 3, 2004
> Another reason Program Files may be on drive D: is a dual-boot system.
Another reason is a clustered computer: drive C: is only what the computer needs to boot, drive D: is shared with the other machine in the cluster (so whichever computer is 'hot' can run whatever is installed on D:).
Christopher Wells
Tuesday, February 3, 2004
"OK, I'll just write a generic update.exe, that takes the name of the EXE to download as input through COMMAND$, download the file through some secure way (WININET.DLL? URLMON.DLL? I understand INET.OCX is not reliable), kill the main EXE, replace it with the new version, launch the new EXE, and kill update.exe."
I hope that won't make your users type this stuff in:
C:\>update.exe myapp.exe
Your application should do this automatically! You would probably want to put all this download code in your main application. Then have your main application run an external app and exit; this external app will copy over all the just downloaded files and restart the application.
Almost Anonymous
Tuesday, February 3, 2004
>>Your application should do this automatically
No, don't worry :-) Currently, I'm looking at either URLMON.DLL or WININET.DLL, so that the updater applet doesn't have any dependency. Besides, I read that the MSINET.OCX is a bit buggy.
One thing about URLMON.DLL's URLDownloadToFile(): By default, it uses IE's cache. I tried three different values for the 4th parameter (&H2, &H10, and &H80000000), but still no way to force URLMON.DLL to ignore the cache and d'load the file every time. Any idea? Thx
FredF
Tuesday, February 3, 2004
"but still no way to force URLMON.DLL to ignore the cache and d'load the file every time. Any idea?"
Don't worry abou that. Let your webserver handle it. If your webserver says the file is new, then URLMON will download it. Probably whenever the file changes on your server, URLMON will download it.
Almost Anonymous
Tuesday, February 3, 2004
>> If your webserver says the file is new, then URLMON will download it
Are you positive URLMON is _that_ sophisticated, or does IE just caches stuff for so many days before emptying it and fetching files again? I'd rather avoid having to include META tags in head sections just to force IE to update its cache.
FredF
Tuesday, February 3, 2004
"Are you positive URLMON is _that_ sophisticated, or does IE just caches stuff for so many days before emptying it and fetching files again?"
IE (and by extension URLMON) honors the web server caching hints. Just make sure your web server is configured correctly (and test it!) and it should work fine.
If in doubt, setup your web server (or use a script) to prevent browsers from caching the download at all.
Almost Anonymous
Tuesday, February 3, 2004
OK, I'll perform more tests tomorrow, with and w/out META tags to forbid caching infos in our download area. BTW, if you have infos lying around on how to download files using WININET.DLL, WINSOCK.DLL, or WSOCK32.DLL as opposed to MSINET.OCX or MSWINSOCK.OCX, I'm interested :-)
FredF
Tuesday, February 3, 2004
us msxml.xmlhttp to download stuff. don't try to manage urlmon or wininet yourself, they're a nightmare.
manage your own one-file cache: track the modified date of the one file you care about. put this in the last-modified header of the HTTP request. (i think you can override this with xmlhttp.)
the hard thing is that you now have two caches. one way to solve it is this: when you've finished downloading the file you care about (xmlhttp loads it to a stream, you write the stream to disk), delete it from the wininet cache (use the wininet function to do this). or have your web server send out the right expires headers and wininet will expire it from the cache pretty soon anyway.
mb
Tuesday, February 3, 2004
Thx for the tip :-)
>> us msxml.xmlhttp to download stuff. don't try to manage urlmon or wininet yourself, they're a nightmare
Damn.. And I thought I had found a good alternative to MSINET.OCX :-)
BTW, what is msxml.xmlhttp? Don't tell me it's something in the .Net framework, as this is a VB5 app.
>> manage your own one-file cache: track the modified date of the one file you care about. put this in the last-modified header of the HTTP request
Good idea. I'll see how to add this tag in the PHP script that returns a file.
FredF
Thursday, February 5, 2004
 Recent Topics
Fog Creek Home
| 
