xp sp3 removing .exe from setup.exe
 

Hi.

My app is sold inet only so the setup file, setup.exe, is downloaded to the users'
computer via the link I send them.
With some users on Vista and XP sp3, the EXE extent of my setup.exe file is removed by the OS or the AV or the firewall, I don't know which.
With some users, they can save the file and add the .exe; with others, there is no such option to save under a different name, it will simply save to desktop as setup, no extent.
Then, a windows office icon is created which, when dbl-clicked, gives Unknown File Type and asks user to select app to open it.
I have the same problem with my demo file, demosetup.exe.

How can I create a demo/setup exe file that will work properly on these pesky OS's?
Thanks.

Windows hides the .exe but it's still there and you can configure Explorer to show it, are you sure this isn't the case?

Hi.
Thx for responding.
This info is from a user.
What he says is the file, setup.exe DL-ed from my site, appears as an icon
on his desktop with no extent after saving, with no option to "Save As'.
He says:
"Going through the process again, when I get to the point of save, I do not see an option to save it as an exe file. The option is; Unknown file type, 1.37 MB, 3.amazonaws.com Save or Cancel And it saves to the desktop if you click save "
And is saved as setup, no .exe.
When he dbl clks it, he gets "unknown filetype" and the "open with" dialog.

Note: the 3.amazonaws.com above refers to the DL server, on amazon.

Any help on this would be most appreciated.
Thx.
Billy

This is likely unrelated to the installer itself.

My guess would be that either the S3 server isn't providing the correct MIME type for the file (application/octet-stream), or the user's browser is ignoring it.

Thx for the suggestion, Anim.
You have seen this before?
If so, would you please give some examples?

I'm not sure how to chk the S3 server output MIME setting.
Is there a way to set a property of a file on S3 to effect this?

Search for "MIME types" for your server type (i.e. IIS, Apache etc)

Stu

Yes - mostly with FireFox users as Internet Explorer used to (maybe it still does - I hardly use it anymore) determine the file type based on the extension rather than the MIME type.

Can't say I know of any currently mis-configured server :)


I'm not sure where you would check in S3 / your server's settings... but if you happen to use FireFox, then the LiveHTTPHeaders add-on ( https://addons.mozilla.org/en-US/firefox/addon/3829 ) will at least let you see what a server sends as a response before the browser begins its download.

Example 1 of a correctly configured host (using IIS).
This uses the generic "application/octet-stream" MIME type.
GET /dir/file.exe HTTP/1.1
Host: www.somehost.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.somehost.com/

HTTP/1.1 200 OK
Content-Length: 115712
Content-Type: application/octet-stream
Last-Modified: Sat, 24 Apr 2010 11:28:47 GMT
Accept-Ranges: bytes
Etag: "91c2694ea1e3ca1:44f"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Sat, 24 Apr 2010 11:29:09 GMT


Example 2 of a correctly configured host (using Apache).
This uses the more specific "application/x-msdownload" MIME type. It also specifies the Content-Disposition filename parameter which a browser -may- optionally use as the name under which to actually save the file, but can't be relied on - but if the MIME type checks out you could see if this parameter is set (incorrectly).
GET /dir/file.exe HTTP/1.1
Host: someotherhost.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://someotherhost.com/

HTTP/1.1 200 OK
Date: Sat, 24 Apr 2010 11:32:02 GMT
Server: Apache/2.0.61 (FreeBSD) PHP/5.2.5 with Suhosin-Patch mod_ssl/2.0.61 OpenSSL/0.9.7e-p1 mod_apreq2-20051231/2.6.0 mod_perl/2.0.3 Perl/v5.8.8
Content-Type: application/x-msdownload
Last-Modified: Wed Apr 7 13:32:41 2010
Content-Transfer-Encoding: chunked
Cache-Control: no-store, no-cache, must-revalidate, pre-check=0, post-check=0, max-age=0
Content-Disposition: attachment; filename="otherfile.exe"
Keep-Alive: timeout=5, max=500
Connection: Keep-Alive
Transfer-Encoding: chunked

Thx Afrow and Anim.

I will try to chk this.
However, this behavior is not for all Windows boxes.
For example, I have tested many XP sp2 boxes where the extent is not removed.
Would this suggest that the MIME encoding is not at fault?

Also, I have never seen the behavior where there is no option to "save as", even if the extent is removed.
In fact, in my instructions to users, I tell them that if the extent is removed, be sure to save it as setup.exe then dblclk to run.

It seems like an overzealous nanny security setting.
I'm wondering if there is a way to "cloak" my setup.exe self-extracting install.

Billy

Yes it could be the users' IE zone settings...

Stu