Microsoft's latest attempt to screw Mac owners

Posted:
in Mac Software edited January 2014
From www.microsoft.com/longhorn article titled "A First Look at Writing and Deploying Apps in the Next Generation of Windows":



For Longhorn, desktop executables are the next version of today's Windows Forms client-side apps. On the other hand, XAML and browser-hosted applications represent an evolution of today's client-side programming model to work over the Web. Right now, existing client-side applications can rarely be deployed over the Web. If you want to embed a Windows Forms form into a browser page, you'll get a reduced feature set and have to tweak bits and pieces of your code. With Longhorn, the common application model will let you write one application and deploy it over the Web. However, the final application is Longhorn-specific?very different from a traditional Web application like ASP.NET.
«1

Comments

  • Reply 1 of 27
    amorphamorph Posts: 7,112member
    They're certainly not the only company headed that way, and they are at least solving the basic problem that web applications with web interfaces suck - the same problem that iTunes uses a different approach to solve. I suppose MS is going to tie this into their idea that you "rent" the use of applications and stream them from a remote server to PCs locked down with copy-protection hardware, but it could also be used to just deploy to a server and stream to clients. That would be nice, at least if it was done right.



    Forte and NeXTStep did something similar (although X11 is the graphical ancestor here), and Apple could easily do it again if they wanted to. WebObjects is basically there as a back end, and it has been for a long time.



    So, meh. This really doesn't screw Mac users any more than MFC or any other Windows API has screwed Mac users. It just means that Longhorn applications can be streamed.
  • Reply 2 of 27
    Well, its a dig in the sense that companies might get the (correct) idea that they can create their web sites in XAML and 97% of the world will be able to see it (read- all but the poor schmucks who bought Macs)...
  • Reply 3 of 27
    amorphamorph Posts: 7,112member
    Well, until someone reverse engineers XAML for Aqua/Gnome/KDE/what-have-you.



    But it would suck if that was seen as a web technology rather than a Windows technology.
  • Reply 4 of 27
    jbljbl Posts: 555member
    Quote:

    Originally posted by Jukebox Hero

    Well, its a dig in the sense that companies might get the (correct) idea that they can create their web sites in XAML and 97% of the world will be able to see it (read- all but the poor schmucks who bought Macs)...



    I agree that this would suck but at what point is it predicted that 97% of the world will use Longhorn? Around here there is no one Windows standard. Some people use 2000 some use XP a bunch still use 98, some even use 95. I am not expecting Longhorn to get over 75% of the windows market for several years after it is released (which looks like it's a couple years off as it is).
  • Reply 5 of 27
    willoughbywilloughby Posts: 1,457member
    Ahhh dammit. I just learned C# and now I gotta learn XAML too. Sheesh.
  • Reply 6 of 27
    Quote:

    Originally posted by Willoughby

    Ahhh dammit. I just learned C# and now I gotta learn XAML too. Sheesh.



    Hahaha... Thats what I said when I ready the article too...



    But its blatantly clear that Microsoft intends for XAML to replace HTML and for it to be tied to the Microsoft platform. There will probably be partial extensions to XP and 2000 to make them use XAML. But Microsoft will leave it at that to cooerce people into Longhorn.









    Really, How long have you (not you, Willoughby) been watching Microsoft do business? And you don't see this pattern a million miles off?
  • Reply 7 of 27
    Quote:

    Originally posted by Amorph

    Well, until someone reverse engineers XAML for Aqua/Gnome/KDE/what-have-you.



    But it would suck if that was seen as a web technology rather than a Windows technology.




    Microsoft is fairly effective at coming up with ways to prevent people from reverse engineering things... It appears that its tied fairly tightly into the whole Microsoft .net framework. How long is this going to take to reverse engineer?
  • Reply 8 of 27
    bartobarto Posts: 2,246member
    Kazaa's Fasttrack was reverse engineered. CIFS/SMB was reverse engineered. The PC BIOS was reverse engineered. Anything popular enough gets reverse engineered.
  • Reply 9 of 27
    Quote:

    Originally posted by Barto

    Kazaa's Fasttrack was reverse engineered. CIFS/SMB was reverse engineered. The PC BIOS was reverse engineered. Anything popular enough gets reverse engineered.



    so hows WINE coming along? How about that project to make Windows drivers work on Linux? How about MONO? What are we up to with word file conversion? 85%?
  • Reply 10 of 27
    Quote:

    Originally posted by Jukebox Hero

    so hows WINE coming along? How about that project to make Windows drivers work on Linux?



    WINE will NEVER work on any Mac unless Mac OS X runs on the Intel/AMD x86 platform. WINE is a recursive acronym that stands for: WINE Is Not (an) Emulator. It simply translates libraries and system calls and runs the binaries natively on the CPU.



    Think of WINE on x86 like you would Classic on PPC. The former needs the latter in order to work.
  • Reply 11 of 27
    ryaxnbryaxnb Posts: 583member
    Quote:

    Originally posted by Brad

    WINE will NEVER work on any Mac unless Mac OS X runs on the Intel/AMD x86 platform. WINE is a recursive acronym that stands for: WINE Is Not (an) Emulator. It simply translates libraries and system calls and runs the binaries natively on the CPU.



    Think of WINE on x86 like you would Classic on PPC. The former needs the latter in order to work.




    No, NO! Classic is an EMULATOR, just not a CPU emulator! WINE doesn't even require Windows to run!
  • Reply 12 of 27
    Quote:

    Originally posted by Brad

    WINE will NEVER work on any Mac unless Mac OS X runs on the Intel/AMD x86 platform. WINE is a recursive acronym that stands for: WINE Is Not (an) Emulator. It simply translates libraries and system calls and runs the binaries natively on the CPU.



    Think of WINE on x86 like you would Classic on PPC. The former needs the latter in order to work.




    Ok. Not an apple to apple comparison. But what Microsoft technology HAS been ported to Apple by someone other than Microsoft? Frankly, XAML frightens me.
  • Reply 13 of 27
    ryaxnbryaxnb Posts: 583member
    Quote:

    Originally posted by Jukebox Hero

    Ok. Not an apple to apple comparison. But what Microsoft technology HAS been ported to Apple by someone other than Microsoft? Frankly, XAML frightens me.



    MS's Office formats have currently been copied to Mac 5,012 times by textedit, appleworks, etc.
  • Reply 14 of 27
    Quote:

    Originally posted by Jukebox Hero

    But what Microsoft technology HAS been ported to Apple by someone other than Microsoft?



    I'm not sure if this answers your question entirely, but Apple's TextEdit can natively read and write MS .doc files and Apple's Keynote can natively read and write MS .ppt files.



    Also, DataViz's MacLinkPlus has been around for YEARS (early-90's as I recall) and can translate oodles of formats including Excel 2.x, 3.0, 4.0, 5.0, 95, 97, 2000, XP 2002; Word (DOS) through v.6; Word for Windows 1.x, 2.0, 6.0, 95, 97, 2000, XP 2002; MS Works for Windows 2.0, 3.0, 4.5, 95; and many more.
  • Reply 15 of 27
    kcmackcmac Posts: 1,051member
    Quote:

    I'm not sure if this answers your question entirely, but Apple's TextEdit can natively read and write MS .doc files and Apple's Keynote can natively read and write MS .ppt files.



    Simple files only. Office v.X doesn't even nail it.
  • Reply 16 of 27
    bartobarto Posts: 2,246member
    Quote:

    Originally posted by Brad

    WINE will NEVER work on any Mac unless Mac OS X runs on the Intel/AMD x86 platform.



    While it would require a lot of work (ie, coding), I don't see any insurmountable obstacles in combining WINE with BOCHS to achieve basic (slow) Windows compatibility on Mac OS X.



    I'm sure that if Microsoft stops developing (if they haven't already) VirtualPC for Mac, the open source community will step in with at least one practical alternative.



    Barto
  • Reply 17 of 27
    Microsoft won't stop development of Virtual PC. Why? Because it sells Windows licenses.
  • Reply 18 of 27
    smirclesmircle Posts: 1,035member
    Quote:

    Originally posted by Jukebox Hero

    [B]

    But its blatantly clear that Microsoft intends for XAML to replace HTML and for it to be tied to the Microsoft platform. ]



    XAML is not a replacement for HTML as we know it. XAML is a way to separate the UI of any application from the backend engine. It is a direct attack on web-based services, but not on websites as we know it.



    If done right, this could be quite a clever technology - something that has been tried quite a couple of times with different approaches - X11, client/server architectures, NextStep among others. Unfortunately they are mixing XAML with C# to get a lock-in to .NETable platforms but in principle, this should have been invented by some consortium like the W3C.



    It will have a deep impact on office applications and maybe on webshops, web auctions etc.. If I was Steve, it would give me the shivers.
  • Reply 19 of 27
    wjmoorewjmoore Posts: 210member
    Quote:

    Originally posted by Jukebox Hero

    so hows WINE coming along? How about that project to make Windows drivers work on Linux? How about MONO? What are we up to with word file conversion? 85%?



    Well the Xbox had sophisticated anti-reverse engineering measures in it and that hasn't stopped people from being able to mod the ROM to run Linux.
  • Reply 20 of 27
    willoughbywilloughby Posts: 1,457member
    Mozilla was first



    I wonder if XAML was an original Microsoft idea
Sign In or Register to comment.