5 ms·

Please explain. Most recent Windows code is written in C# which makes portability easier but even for C/C++ code as long as the api level compatibility is main

Please explain. Most recent Windows code is written in C# which makes portability easier but even for C/C++ code as long as the api level compatibility is maintained ( and no one frankly is better than Microsoft at that game) Windows code should be no less portable. It might be an issue of scale but not portability. Much less software exists for Mac than does for Windows.

ianferrel 15y ago
Apple's done two successful architecture changes on their desktop OS (68k->PPC->x86). Microsoft's done none. Traditionally, MS has been very good at maintaining compatibility through different versions. Maybe they'd make an architecture change easily, but they haven't had to do so yet.
- blinkingled 15y ago
  They have always supported multiple architectures - Win NT ran on Alpha, CE had ARM port, they had IA64 version of Windows server. Technically x86 to x86-64 also is a architecture change and they sailed pretty well thru it given most shipping Windows version today is 64 bit.
  - marshray 15y ago
    It's true! I even know someone who's seen a non-x86/64 Windows system!
    - blinkingled 15y ago
      I am sure it doesnt exist as you sir marshray havent seen it. I must have just woken up from a dream where Windows machines running on Itanium also ran Oracle database ported to Windows Itanium.
      - marshray 15y ago
        You know him too?! Sorry. I concede that there is a major application or three that runs on Itanium. For now. Microsoft is dropping the platform. As for ARM all I'm saying is we'll wait and see.
mitchty 15y ago
Well for one, Apple transitioned from ppc->intel REALLY well with Mach-o binaries and Rosetta. Using a vm/jit isn't the only way to handle architecture changes. In addition it doesn't remove the need to handle kernel changes/etc... that the vm itself runs on. Nor does it mean that the vm and all of its underlying assumptions are valid on a new instruction set. It took java a fair amount of time to run fast on multiple architectures, I doubt .NET will fare any better. When Windows actually manages to (again, it ran on alphas/mips/ppc and something else back in the 4.0 days) run on more than one platform I might partially buy into .NET being "portable" across windows releases and architectures. But I suspect a fair amount of things will have to change or move to new apis. Similar to Microsofts go it alone 64bit model in Windows, another architecture in the fray will force things into spaces they didn't originally expect. Basically, I don't trust anything coming out of Microsoft until they deliver the goods. Apple has shown they can handle multiple platforms transparently, and without the need of a vm/jit. Which can help out things like battery life with caches/etc... http://en.wikipedia.org/wiki/Mach-O http://en.wikipedia.org/wiki/Mach-O http://en.wikipedia.org/wiki/Fat_binary#NeXT.27s.2FApple.27s_Multi-Architecture_Binaries http://en.wikipedia.org/wiki/Fat_binary#NeXT.27s.2FApple.27s... http://en.wikipedia.org/wiki/Rosetta_(software) http://en.wikipedia.org/wiki/Rosetta_(software)
- blinkingled 15y ago
  From CES2011 The technology demonstration included Windows client support across a range of scenarios, such as hardware-accelerated graphics and media playback, hardware-accelerated Web browsing with the latest Microsoft Internet Explorer, USB device support, printing and other features customers have come to expect from their computing experience. Microsoft Office running natively on ARM also was shown as a demonstration of the full depth and breadth of Windows platform capabilities on ARM architecture. I dont think there is reason to doubt Microsoft on API compatibility which i s what this ultimately boils down to. Windows recently ran on IA64 BTW. .NET helps but Win32 in itself is proven enough to need little more than just a recompile for porting.
  - mitchty 15y ago
    I was thinking more along the lines of C/C++ WIN32 api and things like 64bit calling conventions etc... that might not remain quite the same on ARM.
marshray 15y ago
There really isn't that much C# in commercial software, even from Microsoft. You might find an accounting package here or there, but first-tier apps are almost entirely C and C++ under the hood. For example, MS Office and IE are still used primarily in 32-bit mode on 64-bit systems.
- blinkingled 15y ago
  It doesn't matter how much software exists or is in use. We are talking about portability here. For. Net it is is not an issue at all and for Win32 C/c++ only a recompile is necessary. Oracle DB exists for Windows IA64 and office does for Arm. Those are proofs that like any other sane platform portability is not a big issue for Windows.
  - marshray 15y ago
    I think you don't have any idea how much it costs to port a major application like that. Even if everything goes smoothly with the codebase, just setting up another build environment for something like ARM means installing a new compiler version and toolset. Many (or most) dev shops are stuck on 6-10 year old compilers. You also multiply the QA regression cycle costs by some incremental factor. There are lots of applications small and large, that to this day, don't even ship a 64-bit build. Yes, there are some applications that have been ported. Even if you were to come up with a not-short list of them I would submit everything else in the world that has not.
    - blinkingled 15y ago
      I think you are confused as to what exactly we are debating here. Porting costs are real - somehow Mac software isn't magically a free port to ARM. The porting costs depend on code base, complexity, various other things. That's however not what we were debating - the debate was Microsoft has never done it and so it might be hard for them. The counter point I was making was Microsoft has been there and done that and there is no reason to believe Windows software is any harder to port to another platform than Mac Software except for the scale part - Windows just has a ton of more complicated software than Mac has had and porting "toy" Mac apps will be less of an effort than say porting a big Enterprise Windows app. However it isn't fundamentally easier or harder.

ianferrel 15y ago

Apple's done two successful architecture changes on their desktop OS (68k->PPC->x86). Microsoft's done none. Traditionally, MS has been very good at maintaining compatibility through different versions. Maybe they'd make an architecture change easily, but they haven't had to do so yet.

blinkingled 15y ago
They have always supported multiple architectures - Win NT ran on Alpha, CE had ARM port, they had IA64 version of Windows server. Technically x86 to x86-64 also is a architecture change and they sailed pretty well thru it given most shipping Windows version today is 64 bit.
- marshray 15y ago
  It's true! I even know someone who's seen a non-x86/64 Windows system!
  - blinkingled 15y ago
    I am sure it doesnt exist as you sir marshray havent seen it. I must have just woken up from a dream where Windows machines running on Itanium also ran Oracle database ported to Windows Itanium.
    - marshray 15y ago
      You know him too?! Sorry. I concede that there is a major application or three that runs on Itanium. For now. Microsoft is dropping the platform. As for ARM all I'm saying is we'll wait and see.

mitchty 15y ago

Well for one, Apple transitioned from ppc->intel REALLY well with Mach-o binaries and Rosetta. Using a vm/jit isn't the only way to handle architecture changes. In addition it doesn't remove the need to handle kernel changes/etc... that the vm itself runs on. Nor does it mean that the vm and all of its underlying assumptions are valid on a new instruction set. It took java a fair amount of time to run fast on multiple architectures, I doubt .NET will fare any better. When Windows actually manages to (again, it ran on alphas/mips/ppc and something else back in the 4.0 days) run on more than one platform I might partially buy into .NET being "portable" across windows releases and architectures. But I suspect a fair amount of things will have to change or move to new apis. Similar to Microsofts go it alone 64bit model in Windows, another architecture in the fray will force things into spaces they didn't originally expect. Basically, I don't trust anything coming out of Microsoft until they deliver the goods. Apple has shown they can handle multiple platforms transparently, and without the need of a vm/jit. Which can help out things like battery life with caches/etc... http://en.wikipedia.org/wiki/Mach-O http://en.wikipedia.org/wiki/Mach-O http://en.wikipedia.org/wiki/Fat_binary#NeXT.27s.2FApple.27s_Multi-Architecture_Binaries http://en.wikipedia.org/wiki/Fat_binary#NeXT.27s.2FApple.27s... http://en.wikipedia.org/wiki/Rosetta_(software) http://en.wikipedia.org/wiki/Rosetta_(software)

blinkingled 15y ago
From CES2011 The technology demonstration included Windows client support across a range of scenarios, such as hardware-accelerated graphics and media playback, hardware-accelerated Web browsing with the latest Microsoft Internet Explorer, USB device support, printing and other features customers have come to expect from their computing experience. Microsoft Office running natively on ARM also was shown as a demonstration of the full depth and breadth of Windows platform capabilities on ARM architecture. I dont think there is reason to doubt Microsoft on API compatibility which i s what this ultimately boils down to. Windows recently ran on IA64 BTW. .NET helps but Win32 in itself is proven enough to need little more than just a recompile for porting.
- mitchty 15y ago
  I was thinking more along the lines of C/C++ WIN32 api and things like 64bit calling conventions etc... that might not remain quite the same on ARM.

marshray 15y ago

There really isn't that much C# in commercial software, even from Microsoft. You might find an accounting package here or there, but first-tier apps are almost entirely C and C++ under the hood. For example, MS Office and IE are still used primarily in 32-bit mode on 64-bit systems.

blinkingled 15y ago
It doesn't matter how much software exists or is in use. We are talking about portability here. For. Net it is is not an issue at all and for Win32 C/c++ only a recompile is necessary. Oracle DB exists for Windows IA64 and office does for Arm. Those are proofs that like any other sane platform portability is not a big issue for Windows.
- marshray 15y ago
  I think you don't have any idea how much it costs to port a major application like that. Even if everything goes smoothly with the codebase, just setting up another build environment for something like ARM means installing a new compiler version and toolset. Many (or most) dev shops are stuck on 6-10 year old compilers. You also multiply the QA regression cycle costs by some incremental factor. There are lots of applications small and large, that to this day, don't even ship a 64-bit build. Yes, there are some applications that have been ported. Even if you were to come up with a not-short list of them I would submit everything else in the world that has not.
  - blinkingled 15y ago
    I think you are confused as to what exactly we are debating here. Porting costs are real - somehow Mac software isn't magically a free port to ARM. The porting costs depend on code base, complexity, various other things. That's however not what we were debating - the debate was Microsoft has never done it and so it might be hard for them. The counter point I was making was Microsoft has been there and done that and there is no reason to believe Windows software is any harder to port to another platform than Mac Software except for the scale part - Windows just has a ton of more complicated software than Mac has had and porting "toy" Mac apps will be less of an effort than say porting a big Enterprise Windows app. However it isn't fundamentally easier or harder.