I'm actually looking forward to that. I would very much like to have the best of both worlds running at full processing speed in one computer.bag0shite wrote:These new Mactel boxes will allow you to install and run Windows too, if you're so inclined.
Macs to use Intel processors...confirmation at last?
I gotta say m$ are gonna have to pull something real spectacular out of the hat with Longhorn. Pressure's on. Which is all good for us.4g3nt_Smith wrote:I am, since that means a Triple boot of Longhorn, Linux, and OS X. Although, with OS X in its current state, and another update coming before longhorn, it may end up being a dual boot.
At the beginning, yes....licensing will be the next big step, to absolutely cream windows. Just imagine the windows emulation capabilities Apple could implement. With WINE as a solid windows emulation base in unix, they could get practically every bit of software running in the Mac OS, with SDKs for smooth transitions to native mac applications. Then it would be an all out, fair war over who has the more appealing and usable product instead of who has the most software and other third-party infrastructure behind it. I'm guessing this wouldnt happen for another 5-10 years though. Apple still has to build the base and the credibility for such a leap.saturn wrote:Intel-OS X will only run on propietary Mac hardware, otherwise it could be a big threat to MS Longhorn by 2006/2007.
Imagine Apple gaining lead over Microsoft in an OS war....woaaaaaaaaaaaaaaaaa
The first set of benchmarks comparing OSX on *86 to whatever version of Windows is available at the time, oops, I mean XP, will be very interesting :icon31:
Other than that I think m$ are too far ahead for Apple to go head to head with them. Apple need to come up with another killer device, but something better than the iPod which every household will need (think set-top TV box with broadband TV delivery and wireless music streaming) before m$, running whatever Pentium M derivative (and Pentium M is the jewel in the Intel crown since in a cruel twist of fate Intel are having to use AMDs *86-64 extensions) which I'm certain Apple are capable of doing.
Other than that I think m$ are too far ahead for Apple to go head to head with them. Apple need to come up with another killer device, but something better than the iPod which every household will need (think set-top TV box with broadband TV delivery and wireless music streaming) before m$, running whatever Pentium M derivative (and Pentium M is the jewel in the Intel crown since in a cruel twist of fate Intel are having to use AMDs *86-64 extensions) which I'm certain Apple are capable of doing.
I hate people who violently resist change so I will try not to be one of them, but I will be critical of Apple's transition.
[quote="Duhard"]To survive a war you gotta become the war...teammates are useless.[/quote]
[quote="SOAPboy"]You happen to be out of your league when it comes to games.. so fuck off..[/quote]
[quote="GONNAFISTYA"]
I saw
the "Fist Signal" and
came runnin.
[/quote]
[quote="SOAPboy"]You happen to be out of your league when it comes to games.. so fuck off..[/quote]
[quote="GONNAFISTYA"]
I saw
the "Fist Signal" and
came runnin.
[/quote]
-
4g3nt_Smith
- Posts: 711
- Joined: Sun Feb 15, 2004 8:00 am
-
4g3nt_Smith
- Posts: 711
- Joined: Sun Feb 15, 2004 8:00 am
Yeah, I also assume the drivers are the same as Darwin X86 (OSX86®). I've not looked at the CVS tree but I don't imagine there're many options.
Installing the OS on the Mac and transplanting the drive might be possible, assuming you can solve the driver issue. You'd have to make sure rlogin was turned on first!
Installing the OS on the Mac and transplanting the drive might be possible, assuming you can solve the driver issue. You'd have to make sure rlogin was turned on first!
-
4g3nt_Smith
- Posts: 711
- Joined: Sun Feb 15, 2004 8:00 am
My guess is someone will have xp running on one of these boxes before os x running on a garden variety pc. MS wont give a rip if someone gets xp going on it, but apple will sue the first guy who bypasses any restrictions they set to prevent people from booting os x on a Dell. Any box booting OS X will also have stricter hardware requirements, so as long as your Dell has mac-unsupported hardware on it, it wont work anyway for lack of drivers.
[quote="Duhard"]To survive a war you gotta become the war...teammates are useless.[/quote]
[quote="SOAPboy"]You happen to be out of your league when it comes to games.. so fuck off..[/quote]
[quote="GONNAFISTYA"]
I saw
the "Fist Signal" and
came runnin.
[/quote]
[quote="SOAPboy"]You happen to be out of your league when it comes to games.. so fuck off..[/quote]
[quote="GONNAFISTYA"]
I saw
the "Fist Signal" and
came runnin.
[/quote]
-
4g3nt_Smith
- Posts: 711
- Joined: Sun Feb 15, 2004 8:00 am
None the less, given the move to Intel CPUs, I expect more interest arising from the Linux community who will have a UNIX OS with a GUI :-D
Good driver support can't be a bad thing really but I do feel Apple are taking a huge risk as we all know there'll be a hack to get it going on regular PCs.
Saying that, I'll still buy a MacPC (OSX86®) because it'll be good kit that's tried and tested. As my girlfriend says to me (regarding clothes usually), "If you buy cheap, you buy twice". She's Chinese, which makes sense on the money front!
Good driver support can't be a bad thing really but I do feel Apple are taking a huge risk as we all know there'll be a hack to get it going on regular PCs.
Saying that, I'll still buy a MacPC (OSX86®) because it'll be good kit that's tried and tested. As my girlfriend says to me (regarding clothes usually), "If you buy cheap, you buy twice". She's Chinese, which makes sense on the money front!
Ramble after beer...
I've spent some time thinking about the implications of moving my code from PPC to Intel...
At Agfa, where I'm currently working, I've developed a Cocoa app to measure spot colors and save them as ICC profiles. A lot of the code is cross-platform stuff written on Windows and, oddly, first used on the Mac. You should see the compiler warnings from the Windows code we have to compile with GCC!
Writing the ICC profiles means a bit of endian work as the code currently is big endian for the Mac, though there's code there for Intel CPUs. Means a #define to force GCC on Intel down the same path as WIN32 code. No big deal.
The measuring devices we have are another issue as one of the devices is driven by a framework from the manufacturer. Obviously, we need an Intel compiled framework for that framework. Given Gretag's Mac work...
Also, I've written a lot of "float == 0.0f" type code, which will break on GCC Intel. There's a compiler flag which can spot that kind of thing, thank God. I'll have to make a macro to give a tolerance for the comparison (+/- 0.01). I've seen this behavior in the Windows built code and have experienced it before but... who imagined Apple would change CPU! I didn't.
At the moment, I'm writing code to create screens for the Agfa RIP. It's essentially cross-platform XML (read as "Apple plist") using xerces as a parser (my C++ code) rather than the direct Cocoa calls (one line). That's all fine but I have to generate a binary file as an export for the postscript system. I'll have to remember, "htons" and "htonl" are my friends!
FWIW, I've gone through this before, switching from NeXT 68K systems to NeXT (HP Vectra) Intel P60 systems. It's not for free but it's not rocket science. It's mostly irritating as I'm really trying to solve business requirements, not OS crap.
Most Cocoa apps would take a day or so to "port". Carbon (HIView) apps longer and PowerPlant (Adobe/Macromedia) are going to need a lot of work. I wouldn't be surprised if Adobe/Macromedia said, "Just run the Windows version". Their code base is, to be frank, "legacy". I would know given my background! I can say Macromedia are smart guys (and good fun too!). The Adobe (PS) guys seem to be, well, anal.
It's quite a worry at the moment for me as I'm not sure how valuable my skills will be against a million MFC monkeys. I'm hoping that I can still survive because I can deploy quicker than a Windows app.
I can do WIN32 code but I don't want to. It's not very interesting. I've done a fair bit of middle-ware (stock trading) and service level (daemon) work. It's not what I want to do though...
At Agfa, where I'm currently working, I've developed a Cocoa app to measure spot colors and save them as ICC profiles. A lot of the code is cross-platform stuff written on Windows and, oddly, first used on the Mac. You should see the compiler warnings from the Windows code we have to compile with GCC!
Writing the ICC profiles means a bit of endian work as the code currently is big endian for the Mac, though there's code there for Intel CPUs. Means a #define to force GCC on Intel down the same path as WIN32 code. No big deal.
The measuring devices we have are another issue as one of the devices is driven by a framework from the manufacturer. Obviously, we need an Intel compiled framework for that framework. Given Gretag's Mac work...
Also, I've written a lot of "float == 0.0f" type code, which will break on GCC Intel. There's a compiler flag which can spot that kind of thing, thank God. I'll have to make a macro to give a tolerance for the comparison (+/- 0.01). I've seen this behavior in the Windows built code and have experienced it before but... who imagined Apple would change CPU! I didn't.
At the moment, I'm writing code to create screens for the Agfa RIP. It's essentially cross-platform XML (read as "Apple plist") using xerces as a parser (my C++ code) rather than the direct Cocoa calls (one line). That's all fine but I have to generate a binary file as an export for the postscript system. I'll have to remember, "htons" and "htonl" are my friends!
FWIW, I've gone through this before, switching from NeXT 68K systems to NeXT (HP Vectra) Intel P60 systems. It's not for free but it's not rocket science. It's mostly irritating as I'm really trying to solve business requirements, not OS crap.
Most Cocoa apps would take a day or so to "port". Carbon (HIView) apps longer and PowerPlant (Adobe/Macromedia) are going to need a lot of work. I wouldn't be surprised if Adobe/Macromedia said, "Just run the Windows version". Their code base is, to be frank, "legacy". I would know given my background! I can say Macromedia are smart guys (and good fun too!). The Adobe (PS) guys seem to be, well, anal.
It's quite a worry at the moment for me as I'm not sure how valuable my skills will be against a million MFC monkeys. I'm hoping that I can still survive because I can deploy quicker than a Windows app.
I can do WIN32 code but I don't want to. It's not very interesting. I've done a fair bit of middle-ware (stock trading) and service level (daemon) work. It's not what I want to do though...
Well, I have another browser with a project name of, "666.app" which supports Doom 3 and ET. It's part of the http://www.gamesworldonline.net thing I'm working on :-D
Basically, I wrote a Quake3 master clone along with a client SDK. The SDK can be used by any app for finding other games on the internet. I did it when the GameSpy thing happened. We expect to launch pretty soon and I saw some of the web site graphics last weekend... even I was blown away.
Doing an Intel version of the SDK is just a recompilation as all the network code is big endian based (htons etc). It already runs on Windows, Linux and, of course, OSX (PPC).
Basically, I wrote a Quake3 master clone along with a client SDK. The SDK can be used by any app for finding other games on the internet. I did it when the GameSpy thing happened. We expect to launch pretty soon and I saw some of the web site graphics last weekend... even I was blown away.
Doing an Intel version of the SDK is just a recompilation as all the network code is big endian based (htons etc). It already runs on Windows, Linux and, of course, OSX (PPC).
I've been learning C# so I can get a Windows version of 666.app going. It's also something I'm interested in as a "fallback" position with all the Intel Mac stuff.
I fairly like Developer Studio 2005 (beta 2) but it has a lot of poor UI programming in it, IMO. Also the UI construction stuff is primitive. It seems you have to actually write code to get it to do stuff (no KVO features). Reminds me of developing for OS 10.2 at best.
The code editing itself is pretty neat and, been a C# noob, the code completion features are rather useful. It's similar to the VC6 I used to use but jazzed up.
Basically, I spent and afternoon and wrote a simple C# app that could load an image into an image view (knows as a picture box on Windows). I was surprised there was no natural way to embed a view in a scroll view. I'd have thought that was a requirement. I had to manually control scroll bars... this is like writing code for MacOS 6.
Interface Builder pisses all over the Developer Studio UI construction, which makes me happy as it does mean I can deploy a shit load faster than any Windows programmer.
BTW, my Mac code seems to compile with the Intel compiler in XCode 2.1. I don't *yet* have a developer machine to try it out on.
I fairly like Developer Studio 2005 (beta 2) but it has a lot of poor UI programming in it, IMO. Also the UI construction stuff is primitive. It seems you have to actually write code to get it to do stuff (no KVO features). Reminds me of developing for OS 10.2 at best.
The code editing itself is pretty neat and, been a C# noob, the code completion features are rather useful. It's similar to the VC6 I used to use but jazzed up.
Basically, I spent and afternoon and wrote a simple C# app that could load an image into an image view (knows as a picture box on Windows). I was surprised there was no natural way to embed a view in a scroll view. I'd have thought that was a requirement. I had to manually control scroll bars... this is like writing code for MacOS 6.
Interface Builder pisses all over the Developer Studio UI construction, which makes me happy as it does mean I can deploy a shit load faster than any Windows programmer.
BTW, my Mac code seems to compile with the Intel compiler in XCode 2.1. I don't *yet* have a developer machine to try it out on.