Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
the extention .exe cannot be run under osx?
- Thread starter SLJ
- Start date
- Sort by reaction score
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.
But this is also what makes some of the viruses hard to spread to the Mac when they come as a .exe file.
.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
If it's compressed, the standard is generally Stuffit by Aladdin Systems. 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
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
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.
Originally posted by paulwhannel
Very rarely are those .exe attachments worth viewing anyway tho
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!
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.
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.
(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.
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.
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.
All you need is Stuff It. It's just like unstuffing a .sit file.
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.
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!
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.)
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.
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.)
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!
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!