On the Wine mailing list, there is some interesting information on Leopard’s apparent ability to load basic Windows binaries. “When tracking down a crash in the kernel32 loader test, Dmitry found a bug in the Mac OS loader when Wine tried to load his dummy PE file. Upon further research I found that the Mac loader seems to have its own undocumented PE loader built in. I did some further testing with a Windows binary and got some really interesting results.” The first thought was that this was a remnant from Mac OS X’ EFI support, but upon further investigation, this really seems like new, Leopard-specific behaviour: “This is new to Leopard. On Tiger, dlopen rejects PE files as expected. The Wine testing that Steven was originally trying to do would probably not crash on Tiger.” Apparently, Apple is trying its best to hide this behaviour.
So, if they get to the point where you can run win32 programs from OSX that will be cool.
if they can run win32 then the reasons not to switch diminish.
The drawback is if it runs them to well that no-one will develop osx natively (im basing thison what happened with os/2)
I bet if it runs windows it wouldnt be long before MS stopped making a mac version of office and started saying “use the pc version it works, just not as well as on windows..”
Just like nobody writes Cocoa apps, because there’s X11?
If Win32 support comes to OSX on some day, it has to be good enough to be useable, but “bad enough” to not provide any reason to drop support for native app development. Kinda like Cider (Transgaming’s Wine fork) that’s no so good that all those new “native” EA games for Mac are just Win32 binaries wrapped in a Wine bundle.
It also means that programs are going to be much easier to port. You can cobble up together a Cocoa interface to whatever functionality that is contained in Win32 DLL files. This is pretty cool, since there are many commercial libraries that are not available on OS X (the most notable being Direct X).
If they did/do build the ability for osx to run native windows applications, would there be any legal consequences if they didn’t ask MS before hand?
Chances are, what they are using is based on Wine. That’s how *some* Windows apps run on Linux. It would be cool to have Apple contributing to Wine (or really, any usable open-source application).
Edited 2007-11-29 21:58
I find it hard to believe mac could do it on their own. look how long its taken wine to get to the point it’s at now. Then you have to ask yourself, if Apple didn’t get the documention from microsoft, why would they go to all the trouble to reverse engineer the windows api like that? Instead of promoting/trying to get people to port stuff to their own system.
Research I’d imagine. A lot of companies do these sorts of things just to learn more. The great ideas become a product then. Take Google for instance.
Loading PE binaries is not the same as reverse engineering the Windows API.
What Apple has and the Wine team doesn’t is complete access to the Windows XP API. The 1997 agreement between Apple and Microsoft (which ran until 2002) covered cross-licensing technology between the two companies. Windows XP shipped in 2001.
I’ll let Robert Cringely explain the rest:
http://www.pbs.org/cringely/pulpit/2006/pulpit_20060420_000893.html
So it’s not a question of whether Apple can do this, it’s whether they’d have enough reasons to do it.
PE is a file format, albiet one with somewhat hard-to-come-by documentation; the fact that it’s associated with Microsoft means nothing in particular.
Microsoft’d probably be thrilled to discover Apple just gave them about 3-5 million new possible customers of Microsoft office suites and games. For that matter, they might even helping Apple; despite all the juvenile ads, Microsoft remains one of Apple’s biggest vendors.
But I suspect it’s more related to Bootcamp (Apple’s Windows+OSX bootloader) than anything else.
Hard-to-come-by?
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
Is there anything missing in that that means it’s hard-to-come-by?
Apple couldn’t use the information using the license in that page. The license is granted only
“for the limited purpose of implementing and complying with the required portions of this specification only in the software development tools known as compilers, linkers, and assemblers targeting Microsoft Windows.”
I’m surprised if Apple are doing this, not that they are doing this, but because this should have happened and been done and dusted years and years ago.
The real shock here would be Apple having some kind of foresight that they would believe this to be necessary. Whether they have the wherewithall to follow through with this to something meaningful, I don’t know. Personally, I doubt it.
Maybe it’s a development leftover from a time when TransGaming’s Cider wasn’t yet announced and maybe Apple wanted some Windows games compatibility.
“Should have” and “could have” are two very different things, though.
“Should have” and “could have” are two very different things, though.
They should have done this years ago, and they definitely could have done it. Wine has been around for a very long time, notwithstanding the fact that they will only have feasibly been able to possibly run Win32 binaries without some emulator with their move to Intel.
This is why there’s nothing going on here. If Windows compatibility was important to Apple they would have got into it years ago.
Am I wrong in remembering some big cross-licensing deal between apple and MS about when tiger first came out, and before it was revealed they were going intel?
It wouldnt be the first time. It just really sucked before because they had to emulate an x86 proc as well as the API
that’s REALLY interesting!
I would like to see what’s coming there in the future =)
Maybe they plan to have only certain products like Office (and a few more) run on OS X.
While the PE format is a typically Microsoft oriented binary format.. other operating systems have used it in the past (For native applications.)
BeOS used it, prior to their transition to ELF.. ReactOS uses it.. Wine.. and SkyOS did in the past.
Seriously, Just adding support for the PE format doesn’t mean you’re trying to emulate the Windows API.
(Some of you are just so uneducated it frightens me..)
P.S, It’s not an undocumented format either.. It’s just a modification of COFF.
nono, YOU are uneducated! It’s obviously a conspiracy! MS is trying to secretly turn OSX into its new OS. They are paying off Apple to keep it a secret until they have a few… kinks… worked out before they announce it to the world. Then they will finish buying all of Apple and changing OSX to MS Windows OS v10 extreme edition.
And somewhere linux fits into this.
Duh.
Edited 2007-11-29 23:02
Seriously, Just adding support for the PE format doesn’t mean you’re trying to emulate the Windows API.
No it doesn’t. I assumed there was something more going on here. There isn’t now that I’ve read the ‘thread’, such that it is. However, they do say that this might be a ‘sign’ of a future Win32 subsystem. It doesn’t mean that there will be one, and it doesn’t mean that this isn’t just some leftover from somewhere else.
Additionally, from a logical point of view, if this was the case it would have been started and done years ago. Hey, this is Apple we’re talking about here.
Edited 2007-11-29 23:38
They never said the PE format is undocumented…. they are saying that Leopard is trying to hide it’s builtin support by not documenting it….
Why are you writing about Wine in this sentence…. OF COURSE there is support for PE format in Wine… Wine is made for that and that’s how they found the hidden loader
They never said the PE format is undocumented…. they are saying that Leopard is trying to hide it’s builtin support by not documenting it….
This could have come from absolutely anywhere, and is not really indicative of anything that Apple might be doing.
This isn’t required for .Net compatibility, and there is a huge difference between having a PE loader and implementing a Win32 system. That’s a huge amount of work, and that’s why if they were going to do this then it would have been looked at years ago.
Do you notice something in common with the examples you provided? They all used it at one point, but no longer do. Even if Apple cared about any of the examples mentioned, which I find hard to believe, it just doesn’t compute that they’d implement a format which none of them currently use.
Your so presumptive it frightens me……
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/conf/GENERIC?…
Look for #options COMPAT_PECOFF # kernel support to run Win32 apps. This lingers in there since at least NetBSD 1.6. I’ve always been wondering if i could take it to some good use 🙂 Never tried though.
My best guess would be that it is some unintended, leftover kernelconfiguration from some build which slipped through QA/QM. No news here, move along.
The option doesn’t hint at WIN32 support, but at PE/COFF support.
Rather like assuming that the fact that a Scoda has a speedometer indicates the presence of a working engine.
… people would stop developing Cocoa apps because all of a sudden you could programme for Win32 is ridiculous. Do you know what Win32 is like?!
Anyways, it’s not a lack of software that’s keeping the Mac back. It might be the perception of a lack software, but even that I don’t think…
For me its the lack of alternative themes, the one button mouse thing (correct me if this is history now), and the fact that although there is plenty of software, most of it costs money, meaning I’d have to shell out tens of thousands of dollars to get the same functionality I currently enjoy on Linux.
That argument also works for windows. It just costs too much.
back on topic…I dont think this has anything to do with apple being able to run windows programs. As mentioned before, it would require all the same work than the wine project has done thus far and even then you’d only have partial compatibility. Plus I dont think apple is that interested in this concept. If they get enough market share, developers will write native apps for OSX anyway, which is far better.
The current Mac mouse is an optical mouse which has four ‘buttons’ and a mini-trackball where the middle button goes. (Unfortunately, I put ‘buttons’ in quotes because they are based on case pressure, not actual physical switches, and so it’s a very touchy mouse to use.)
[q]and the fact that although there is plenty of software, most of it costs money, meaning I’d have to shell out tens of thousands of dollars[q]
There’s a lot of freeware software, and since you use it, a lot of open-source software has been ported to Mac. The biggest problem preventing the Mac’s adoption is their 80s-style hardware lockin.
(“Upgrades? We ended support for your system a long time ago — we don’t even use the same chipset or kernel anymore, now that we’ve found out it’s much more profitable to sell you freeware code with a minimalistic eye-candy wrapper at highly inflated prices. Here, shop for a brand new machine and brand new software, which we won’t guarantee will be compatible with any future versions of the hardware OR the OS. But it’s okay — we’re not Microsoft and we have the iPhone and iTunes, so you’re required by geek law to love us.” Yeah, I’m a bit bitter.)
Yeah, I’m a bit bitter.)
Clearly.
That and if you press both the left and right mouse button only one will respond (the left). The buttons are actually touch sensitive the button you are pressing is already registered before you click the button. So the two button problem will happen even if you click the right mouse button or not as long as you have your finger anywhere near the area. The problem of it not registering both buttons if they are both are pressed should be fixed though.
Lol! Well said.
The rest of your post was spot on as well, +1 from me.
Three buttons actually, the side ‘grey areas’ act as one squeeze button.
Left, right, middle button (on the trackball) and side buttons (act as one) = 4
You’re right, sorry, I count the trackball ‘button’ as part of the trackball function.
I use the alternative and quite popular UNO theme.
It’s history since about 10 years (even before the release of Apple’s Mighty Mouse there was multi-button support in Mac OS).
I don’t know where you get your “facts” from, but I almost exclusively use Free Software under Mac OS X. The big exception for me is iTunes that’s just freeware and not Free Software.
OK, most things I do are just common user stuff. If I worked in professional media production, I probably had bought Final Cut Studio. FCS costs a few bucks (it’s cheap compared to equal software from Avid), but OTOH there isn’t even FCS-like software for Linux.
Edited 2007-11-30 19:17
Software – Bogus argument. Whatever you have on Linux for free, you can run on mac (they come with X11 out of the box). I’m even running GNOME and KDE programs natively in OSX. If you want to pay for quality programs, you can also do that. Most Linux software has free Mac-only equivalents too. Tens of thousands of dollars!?? I seriously doubt that. You’d need 10 licenses of Matlab AND the Adobe CS3 Suite to cost that much, and there’s no absolutely way you can do that stuff in Linux for free.
Alternative themes – Shapeshifter does this, though it’s not free. The default OSX theme is nice enough though and doesn’t offend anyone. It’s even what I use on my Linux machine
One button mouse – only Apple *laptops* have one button (but support right-clicking), however Apple mice are multi-button, and OSX has always supported right-clicking and 3rd party USB mice.
There’s other reasons for choosing Linux over OSX, but if those are your reasons, you should try OSX
It isn’t bogus. I’ve seen how running Unix software on the Mac is like, and it’s tedious compared to Linux (and I mean Ubuntu specifically).
For example, the SSH server (I don’t remember whether it was installed by default or not) was not configured by default. It should be. It’s configured by default when I install it in Ubuntu. You can argue that it’s “easy to configure sshd” but the fact is I *shouldn’t* have to!
Ditto for the development environment. It’s a pain compared to Linux – things just aren’t setup correctly out of the box! After installing MySQL, a friend of mine (who is a huge Apple fan and OS X user) tried installing Ruby on Rails. It didn’t work – the MySQL gem failed to find the MySQL header files. It took me an hour of messing with the command line to fix his setup. Now you can argue that this is the third party’s fault, but frankly, nobody really cares whose fault it is! The fact remains that, after installing the MySQL headers on Linux, compilation *just works*, which is not true on OS X.
And finally, the APT software repositories for OS X are tiny compared to Ubuntu. Lots and lots of useful software aren’t in the repositories. OS X users will quickly have to rely on compilation – not very user friendly. On Linux, 99.99% of the time I can click “Start”->”Add/Remove Software”, select what I want, click Apply, and I’m done.
No this is not a joke. I know this is an unpopular opinion and I’ll get modded down to hell for this. But my Mac-using friend is considering switching to Linux. The only thing preventing him from trying out Ubuntu is that he can’t figure out how to boot his MacBook from a CD.
Edited 2007-12-01 08:48
… is that it’s still buggy and doesn’t fully work yet.
What I wonder about this is, if OS X had the ability to run Windows binaries, wouldn’t this make OS X susceptible to various forms of Windows malware? (Of course, the malware would have to come with two sets of instructions: 1) What to do if activated on a Windows system and 2) What to do if activated on an OS X system.)
Edited 2007-11-30 00:15
Well that and…
3) Apple would have to turn off every bit of the UNIX security model in OSX.
I doubt that they would go out of their way to support win32, it would be a wasted effort. Even for the Windows world, win32/win64 is a dead end, the future is .NET.
.NET uses PE, so for all we know, Apple might be working to develop support for .NET; it wouldn’t cause issues (aka the OS/2 effect of emulation being too good thus killing off native applications) and provide a reasonable level of compatibility with Microsoft in the future.
It won’t mean 100% compatibility – because that isn’t truly needed, as long as there is enough compatibility there which allows porting of applications without major rewrites of the whole application, it should mean that development will be easier in future.
I wouldn’t be surprised if by 10.6 if we see an agreement between Apple and Microsoft by way of Apple getting access to the MSN protocol, WMA/WMV/ASF CODEC support etc. etc.
The .NET support is what I am thinking as well. The effort to hide it implies that something is coming. And for all of the people saying *BSD has had this, its not been like this. This is new. Read my emails on the subject before you comment.
True, there was a bit of a debate on whether Mac OS X would officially support .NET given that they support Java as well.
Although Apple have Objective-C 2.0 which has memory management, I doubt it would go beyond Mac OS X hence the reliance I’d say on the technological turf warfare that goes on between Sun and Microsoft.
But unfortunately they see PE and they instantly assume “Windows compatibility” – even if it has nothing to do with Windows compatibility.
Pardon – who are you directing that rude reply to. Learn some manners.
Edited 2007-11-30 06:56
I don’t think it was directed at you, but rather at “all the people saying *BSD has had this”…
.NET support shouldn’t require the dyld to understand PE: none of the code in a .NET PE executable needs to be loaded (because it’s just a stub that invokes the .NET loader).
The future may be .NET, but it’s not one that Microsoft have even embraced yet for anything except utilities.
And, to others: the likely reason Apple didn’t do this “years ago” was because it would have required building an x86 emulator into the dynamic loader as well…
You never know, perhaps Apple’s revisiting Pink… or Taligent, only without IBM’s help this time.
It’s still possible that it is related to .NET support.
Microsoft’s SSCLI runs on OS X as does Silverlight. Silverlight 2.0 will contain a complete .NET runtime.
It seems likely that Microsoft will work with Apple to write a complete .NET implementation for Mac OS X (much like Sun does with Java).
My theory on the PE support is that early development work for .NET for Mac has already begun and that some of the native code that .NET relies on is still in PE format binaries.
I could imagine a situation where Library A depends on Library B, but Library A does not make any OS calls. If Library B is ported then Library A will work “for free” as long as the binary can be loaded.
Supporting windows apps should allow apple to install and run the .NET framework aswell.
Quite why Apple would want to do this is another matter
And why wouldn’t they want to do that. Do Apple executives like to forbid people from doing useful things?
Just the idea of making an effort to get .Net working seems pointless. Kind of like modifying a Porche to be able to fit a Skoda engine.
FreeBSD and NetBSD both have compat/pecoff. Maybe that’s what people are seeing?
Well, since it’s supposedly new behavior in Leopard, it seems to be something Apple as chosen to add at this point, for one reason or another.
Maybe they picked it up by refreshing the source code from BSD that they use in their new builds.
Or maybe it’s the other way around – Apple wants to port the OSX API to Windows and in order to have the same binaries running on both OSX and Windows they switch to the PE format.
Quite unlikely but still a possibility – especiallywith an inferior Windows implementation.
Edited 2007-11-30 12:29
I wondered if this was something to do with a development in the fat binary concept, if the univeral binary format were to be changed to work on Windows as well, then the universal-binary parsers would have to understand the PE format.
I don’t have anything really useful to contribute to this discussion, but since it’s an opportunity to cast some derision Microsoft’s way…
If there is a binary file format worse than Mach-O, it’s PE. Yes, it’s an extension of COFF, but COFF wasn’t that great and PE is a _really_ big and hairy extension. It’s suck-tasticness boggles the mind really.
ELF isn’t perfect, but it’s an absolute shining pinnacle of virtue in comparison to either Mach-O or PE.
http://themacsucks.com/joomla/content/view/414/28/