PDA

View Full Version : the extention .exe cannot be run under osx?


SLJ
Jul 23, 2003, 10:54 PM
i am new to OSX & Apple Mac... anyway, I want to know if the .exe extention can be run under OSX or .exe is not for apple mac all together? Someone send me a file which have .exe and I am not sure how to run it...

Sun Baked
Jul 23, 2003, 11:00 PM
Usually it means it's a Window's file, but sometimes some of the compressed files with that extension can be opened using some of the third-party programs.

But this is also what makes some of the viruses hard to spread to the Mac when they come as a .exe file.

Vlade
Jul 23, 2003, 11:09 PM
.exe means a windows program, so 99% of the time you can't open it, just like you cant open a .app file on a PC

SLJ
Jul 23, 2003, 11:15 PM
hmm, okay thank guys... so if a .sit unpack a .exe? that is still a PC file right?
Anyway to convert it or which 3rd party program do I need to use to open?

rainman::|:|
Jul 23, 2003, 11:39 PM
If it's compressed, the standard is generally Stuffit by Aladdin Systems (http://www.aladdinsys.com/). They have a free version and a pay version.

You can also use .exe files by purchasing VirtualPC, which lets you run a Windows enviroment on your Mac, albeit very very slowly... It still comes in handy for occasional stuff, like email attachments.

Very rarely are those .exe attachments worth viewing anyway tho ;) Once you've seen elf bowling once, you've seen it a thousand times...

pnw

NNO-Stephen
Jul 24, 2003, 12:35 AM
yeah, generally a .exe cannot be opened on a Mac. .exe is the Windows equivalent of a .app which can only be opened on a macintosh.

Flowbee
Jul 24, 2003, 12:56 AM
Originally posted by NNO-Stephen
yeah, generally a .exe cannot be opened on a Mac.

Thank God! That's why I switched. :cool:

voicegy
Jul 24, 2003, 01:01 AM
Originally posted by paulwhannel
Very rarely are those .exe attachments worth viewing anyway tho ;) Once you've seen elf bowling once, you've seen it a thousand times...
pnw

hahaha! EXACTLY! I've yet to see one that was worth keeping...and I'm personally GLAD that the Mac OS can't run them. They're the #1 Time-Waster in offices everywhere...besides Windows itself, of course! :)

Doctor Q
Jul 24, 2003, 01:06 AM
Originally posted by SLJ
hmm, okay thank guys... so if a .sit unpack a .exe? that is still a PC file right?
Anyway to convert it or which 3rd party program do I need to use to open? It is unusual to find an .exe (Windows executable) file within a .sit (StuffIt) file, because StuffIt is one of the standard compression and packaging formats for Macintosh files as is rarely used for Windows files. In the Windows world, .zip format is the standard for compression and packaging. In the Unix world (which includes Mac OS X), .tar is the standard packaging format and .Z and .gz are the standards for compression.

By "standard" I mean "most common". There is nothing to prevent any file from being compressed and/or packaged in any of these formats.

SLJ
Jul 24, 2003, 01:11 AM
Yes, I learned from the hard way, I just downloaded a file - which is 200MB and my mac have no idea what do to with it and I have no idea what do to with it... now I have to seach for the mac version of the file.

zimv20
Jul 24, 2003, 01:31 AM
unix doesn't identify files by the extension. it uses something inside the file called a magic number.

(individual apps, however, may rely on the extension)

so -- an .exe that doesn't work on unix has problems because it has a missing or malformed magic number (being a PC-only file would cause that), not because of the extension.

as humans, we recognize the .exe extension and associate it w/ windows. but unix doesn't care.

maradong
Jul 24, 2003, 04:42 AM
Originally posted by zimv20
unix doesn't identify files by the extension. it uses something inside the file called a magic number.

(individual apps, however, may rely on the extension)

so -- an .exe that doesn't work on unix has problems because it has a missing or malformed magic number (being a PC-only file would cause that), not because of the extension.

as humans, we recognize the .exe extension and associate it w/ windows. but unix doesn't care.
exact => 5/5
great summary ;-)

mrjamin
Jul 24, 2003, 07:36 AM
Originally posted by zimv20
as humans, we recognize the .exe extension and associate it w/ windows. but unix doesn't care.

and that, my friends, is one of the hundreds of reasons why OSX + all other Unix OS's are far superior than all things Windoze.

zimv20
Jul 24, 2003, 10:27 AM
Originally posted by maradong
exact => 5/5
great summary ;-)

thank you

zimv20
Jul 24, 2003, 11:01 AM
Originally posted by mrjamin
Unofficial Marketing Manager to Wing


hey! a friend sent me her link a couple months ago. i forwarded it and, pretty soon, they stopped offering mp3 samples.

have you actually gone on and bought CDs?

Abstract
Jul 24, 2003, 01:19 PM
You can't open .zip files on a Mac, right? I've never even tried.

Juventuz
Jul 24, 2003, 01:28 PM
Sure you can, I've unzipped plenty of files on my Mac. They almost always contain pics that Windoze users send me though.

All you need is Stuff It. It's just like unstuffing a .sit file.

GeeYouEye
Jul 24, 2003, 04:49 PM
There are rare occasions when .exe files can be run... the Folding@home core is an .exe file for example. Just has to be run in the Terminal.

voicegy
Jul 24, 2003, 11:50 PM
Originally posted by mrjamin
Unofficial Marketing Manager to Wing


hahaha! you ROCk, mrjamin. Thanks to you and MacRumors, Wing got more hits than it could handle.

zimv20, someone I sent the link to weeks ago bought one of her cd's and made me a cassette tape of it. It's WONDERFUL!:p

zimv20
Jul 25, 2003, 11:42 AM
Originally posted by voicegy

zimv20, someone I sent the link to weeks ago bought one of her cd's and made me a cassette tape of it. It's WONDERFUL!:p

sweet. i love this quote from her homepage:

I have worked hard and I hope you have all found I am improving.

cnladd
Jul 28, 2003, 05:55 PM
Originally posted by zimv20
unix doesn't identify files by the extension. it uses something inside the file called a magic number.

(individual apps, however, may rely on the extension)

so -- an .exe that doesn't work on unix has problems because it has a missing or malformed magic number (being a PC-only file would cause that), not because of the extension.

as humans, we recognize the .exe extension and associate it w/ windows. but unix doesn't care.

Close.

Yes, it's true that Windows and DOS uses file extensions to determine whether something is executable or not. UNIX, however, uses permissions -- if something has the executable set and you try to execute it, the kernel will attempt to execute it.

How the file gets executed, however, is similar on Windows/DOS to the way its done on UNIX.

DOS will look at the first couple of bits of the file to determine how the file gets executed. Take a look at an .EXE file and you'll notice that the first two bytes are "MZ". There are similar bytes for .COM files. There are other bytes that will further determine what kind of .EXE file it is, how it uses memory, etc.

UNIX also looks at the first few byes, as well as a few others. UNIX is a bit more comprehensive, however, in its methods. There's a file called /etc/magic that UNIX uses to determine what type of file it is (it can even recognize, though not execute, DOS binaries.)

The "magic number" just identifies the type of file and how it gets executed (if at all.) Whether it gets executed or not depends on the extension (in DOS and Windows), or on the executable bit (in UNIX.)

Doctor Q
Jul 28, 2003, 08:18 PM
As long as we're explaining how executables work, here are some more details about scripts...

Unix can identify a script (a readable text file containing commands in an interpreted language) by the characters #! at the front of the file. Following the #! you can put the path to the interpreter (an executable that will be invoked to interpret your file). The default is usually the Bourne shell or the Korn shell (e.g., path /bin/sh). This is how shell scripts (Bourne, C, Korn, Bourne again, tcsh, etc.) get invoked. Same for Perl scripts.

If a file is a shell script, it may not have to have execute permission because it is the interpreter (e.g., /bin/perl) that must be executable, while the file containing the script only needs to be readable.

zimv20
Jul 28, 2003, 09:03 PM
Originally posted by Doctor Q

If a file is a shell script, it may not have to have execute permission because it is the interpreter (e.g., /bin/perl) that must be executable, while the file containing the script only needs to be readable.

afaik, if you're typing the name of the file, you need to chmod it to be executable. try it.

cnladd
Jul 28, 2003, 10:29 PM
Originally posted by Doctor Q
As long as we're explaining how executables work, here are some more details about scripts...

Unix can identify a script (a readable text file containing commands in an interpreted language) by the characters #! at the front of the file. Following the #! you can put the path to the interpreter (an executable that will be invoked to interpret your file). The default is usually the Bourne shell or the Korn shell (e.g., path /bin/sh). This is how shell scripts (Bourne, C, Korn, Bourne again, tcsh, etc.) get invoked. Same for Perl scripts.

If a file is a shell script, it may not have to have execute permission because it is the interpreter (e.g., /bin/perl) that must be executable, while the file containing the script only needs to be readable.

Yep, you're right. The "#!" at the beginning is typically called a "shebang" and happens to be the "magic number".

A shell script still needs to have execute permission, as does the interpreter itself. The only exception is for a script that gets sourced in by another script (a good example is a typical .profile file.) These scripts do not need to have the execute bit set, as they are only read in by the sourcing script (with commands executed under that script's context.)

Doctor Q
Jul 28, 2003, 10:58 PM
In Terminal, you invoke commands by typing the command name, or a path and command name. When invoked that way, the command should have execute permission. But you can also invoke a shell script by naming the shell and the shell script file, e.g., sh myscript, in which case the shell script only needs read permission.

Programs and scripts can also be executed by the operating system or by other applications. Examples: The at, batch, and cron commands execute commands in the background (i.e., without showing their output on the screen) on a sheduled basis. A web server (e.g., Apache) will execute commands in its cgi-bin directory when the appropriate URLs are specified by a web browser connecting to that server. And lots of applications have plug-ins, filters, and other extras that are executable code. So there are lots of ways that programs get invoked!

zimv20
Jul 28, 2003, 11:23 PM
Originally posted by Doctor Q
you can also invoke a shell script by naming the shell and the shell script file, e.g., sh myscript, in which case the shell script only needs read permission.


ah, i gotcha. yes, in that case the name of the file is an argument and the shell deals w/ it only in the sense it's passing the name to the sh program. when sh opens a pipe to read the file, it only needs the read bit set, as you indicated.

i thought you meant you were executing the file directly, e.g.:

% myscript

cnladd
Jul 28, 2003, 11:25 PM
Originally posted by Doctor Q
In Terminal, you invoke commands by typing the command name, or a path and command name. When invoked that way, the command should have execute permission. But you can also invoke a shell script by naming the shell and the shell script file, e.g., sh myscript, in which case the shell script only needs read permission.

Programs and scripts can also be executed by the operating system or by other applications. Examples: The at, batch, and cron commands execute commands in the background (i.e., without showing their output on the screen) on a sheduled basis. A web server (e.g., Apache) will execute commands in its cgi-bin directory when the appropriate URLs are specified by a web browser connecting to that server. And lots of applications have plug-ins, filters, and other extras that are executable code. So there are lots of ways that programs get invoked!

True, but we're not talking about invoking a command here. Instead the discussion has centered around simple execution and how an OS determines that a file is executable. In your examples, the scripts are not then executed directly. Instead, the shell itself is executed and directed to read the contents of the script and invoke the commands contained therein. It's a method of invoking the script, true, but the script isn't itself executed.

If you want to get into the nuts and bolts of a script, the script itself is never properly executed. Instead, the interpreter (either the default or the one specified after the shebang) is executed and the remainder of the script is used as the input.

In the case of batched jobs (batch, at, cron, etc.) commands that are run do need to be set as executable.

BrandonRP0123
Jul 29, 2003, 09:34 PM
Originally posted by paulwhannel
Very rarely are those .exe attachments worth viewing anyway tho ;) Once you've seen elf bowling once, you've seen it a thousand times...

pnw [/B]


99% of the .exe attachments I receive from others are - you guessed it - viruses.

Or .pif files or .bat files. I just look at them and laugh - knowing that somewhere out there a PC is being compromised from this very e-mail.

cnladd
Jul 29, 2003, 09:57 PM
Originally posted by BrandonRP0123
99% of the .exe attachments I receive from others are - you guessed it - viruses.

Or .pif files or .bat files. I just look at them and laugh - knowing that somewhere out there a PC is being compromised from this very e-mail.

Last week I got an e-mail, cleverly disguised as a bounceback message -- it made it look like I tried to send a file to someone and it failed.

The attachment they made it look like I was trying to send was a .EXE file. Clever.

For some odd reason, none of my coworkers would let me try to run it on their windows boxen so I could see what it was. :(

Doctor Q
Jul 29, 2003, 10:14 PM
You may not be able to (or want to) run a suspicious .exe file, but you might be able to peek at some of the messages it contains with the strings command in Terminal.

Example: You saved e-mail attachment im_not_a_virus_really_im_not.exe to your Documents folder. Type the command

strings -20 ~/Documents/im_not_a_virus_really_im_not.exe

to see all strings of at least 20 consecutive ASCII characters in the file. If one of the messages is "Ha ha, I erased your C: drive!" then you'll have a clue what the mysterious .exe file might be.

cnladd
Jul 29, 2003, 10:27 PM
Originally posted by Doctor Q
You may not be able to (or want to) run a suspicious .exe file

My wanting to run it on a coworker's machine was meant tongue-in-cheek. Sort of a "Hey, I think I got a virus, but it won't work. Can I try it on your Windows box?" type of scenario.

As an aside, folks on the Windows side of the fence are often taught early on to not open up attachments from people they don't know ("Don't accept candy from a stranger".)

UNIX admins are suspicious by nature, so that advice goes without needing to be stated.

But what about from a Mac perspective? I haven't yet received a strange Mac binary in an e-mail or otherwise. I understand that its due mostly towards lower userbase, but does that phenomenon exist at all on the Mac?

Doctor Q
Jul 29, 2003, 11:15 PM
Actually, I understood your tongue-in-cheekiness. But it seemed like a good opportunity to mention another tip. So go ahead and test your viruses on your co-worker's PC!

I have never met a Mac virus, in an attachment or otherwise. Other than the platform-independent Word-macro viruses, the last one I read about for Mac was a humorous one, not a harmful one, and it was under System 7!

I'm sure there are some out there, but I certainly don't worry about them.