Coffeehouse Thread

146 posts

Conversation Locked

This conversation has been locked by the site admins. No new comments can be made.

Microsoft still in denial

Back to Forum: Coffeehouse
  • Deactivated User

    Comment removed at user's request.

  • contextfree`

    @wastingtimewithforums: FYI, avoiding "classic modes" is just a general rule for the UEX teams these days, it's not specific to any particular UI change. (they didn't have one in Office 2007 either for example, and the Windows classic theme was removed in Windows 7) This was a direct result of their experiences with past "classic modes" like the Win95/XP ones you mentioned, which turned out to be a PITA to maintain and at some point they swore never to do that again.

  • PaoloM

    Also, more than 80% of Windows XP users never changed the default theme from Luna blue to anything else.

  • Retro​Recursion

    , Bas wrote

    Haven't they always stated that this is what desktop apps are for?

    In one of the Build talks about LOB metro apps, they indicated that we should have no problem porting 98% of our apps to store apps, but that the 2% remaining could stay on the desktop as "legacy". That seems out of touch with reality.

    The store version of Microsoft apps I've seen are all simplistic reductions to their desktop counterparts. Look at Messenger and Lync as examples. I would like to see examples from Microsoft of complex apps working with the Modern UI.

  • blowdart

    , Visible = False wrote

    The store version of Microsoft apps I've seen are all simplistic reductions to their desktop counterparts. Look at Messenger and Lync as examples. I would like to see examples from Microsoft of complex apps working with the Modern UI.


    I prefer the Lync store app *shrug*

  • Retro​Recursion

    , evildictait​or wrote

    The only people saying that "Metro is the future" and the "desktop is deprecated" are people who haven't engaged their brain 

    In that case, the guys from Microsoft are not engaging the brain then. The Build talks that spoke about LOB apps in Windows 8 place heavy emphasis on moving to the new UI. They spoke about 98% of LOB apps can be moved over. They repeatedly state that developers should "move their apps forward" to the new UI. They repeatedly state that the desktop is the "old" and that we should move to the "new".

    I realize that we can still use the desktop, but my experience has been that it is more difficult to deploy .NET applications on Windows 8 than at anytime in the past. Just the fact that it took us 4 weeks to figure out how to automatically activate .NET 3.5 on a Windows 8 system that does not already have it activated is ridiculous. To me, this points to the fact that the desktop area is entering the legacy phase.

  • evildictait​or

    , Visible = False wrote

    *snip*

    In that case, the guys from Microsoft are not engaging the brain then. The Build talks that spoke about LOB apps in Windows 8 place heavy emphasis on moving to the new UI. They spoke about 98% of LOB apps can be moved over. They repeatedly state that developers should "move their apps forward" to the new UI. They repeatedly state that the desktop is the "old" and that we should move to the "new".

    Build is about new Microsoft technologies. That's why they talked a lot about the new UI.

    And yes, you can put some LOB swishy apps in the new UI. But Microsoft aren't expecting you to migrate your massive WinForms projects into an iPad-suitable format any time soon.

    To me, this points to the fact that the desktop area is entering the legacy phase.

    Let me make this very clear. Microsoft goes to freakishly bizzare efforts to make your apps from Windows 95 work on Windows 7. They have teams of people to patch opcodes in Adobe Reader 6 to make it work on Windows7 and they hook GetVersion() to return "yes I'm really Windows 98" for the apps that say if(GetVersion() != Windows98) abort().

    That right click menu on shortcuts to change what compatability the app runs as? That took thousands of man days testing millions of products to build.

    They refused to change the default caption size in Windows7 because it broke a couple of minor apps that frankly nobody's ever heard of, and that annoying thing where for ages running VLC would cripple Aero and take you back to the "basic theme"? AppCompat yet again.

    Microsoft refuses to change function signatures and can't kill old crusty functions like GetAtom() - which returns an ATOM not a BOOL for the one program written in 1997 that gave a crap, and a cursory examination of LoadLibraryA shows that the first thing it does is call strcmp(_param, "twan32.dll") to keep some old crusty apps from breaking.

    There's shims in Microsoft for Baldur's Gate, thunking layers to take DirectX9 apps to DirectX11 because DirectX9 doesn't exist in Windows8, and the entire WOW64 layer is there to keep apps compiled for 32-bit by emulating every single damned syscall because the kernel contains only 64-bit code.

    There's even an entire fake directory structure in the Windows directory and the registry (C:\Windows\syswow64) which appears as C:\Windows\system32 to 32-bit apps just to maintain binary compatibility with old and crusty apps that aren't 64-bit aware.

    My point is that Microsoft goes to absurd lengths to make sure that an app you compile today will work 10 years down the line, no matter how much they change under the hood in Windows. There is not a cats chance in hell that Microsoft are going to stop supporting desktop applications in the foreseeable future - not after they've staked their entire reputation on maintaining binary compatibility with apps from before coding standards or MSDN online documentation existed..

    So when you say "Oh, I should stop writing apps for the desktop because Microsoft might can the desktop in the next year or so" my response is thus:

    Balderdash.

    The desktop is here, it's here to stay. And frankly if you're worried about the future-proofness of your apps, then look at WPF versus WinForms. New things are easier to bin than old things at Microsoft. So don't believe everything you hear at Build.

  • TexasToast

    , Visible = False wrote

    *snip*

    I realize that we can still use the desktop, but my experience has been that it is more difficult to deploy .NET applications on Windows 8 than at anytime in the past. Just the fact that it took us 4 weeks to figure out how to automatically activate .NET 3.5 on a Windows 8 system that does not already have it activated is ridiculous. To me, this points to the fact that the desktop area is entering the legacy phase.

     

    You must not have tried side loading for your Enterprise yet.   You will change your mind on what is easier (Windows Store App side loaded versus desktop on Windows 8). 

  • Retro​Recursion

    @TexasToast: I have and it's okay for basic apps and dashboards. But unfortunately that does no good for most business apps since WinRT is so limited at this point. For example, if you go the Windows Store route you are stuck with SQLite. A very limiting alternative to the more powerful tools from Microsoft. It seems crazy to me that they are encouraging developers to move business applications to that environment but do not have a database solution to offer.

  • blowdart

    , Visible = False wrote

    It seems crazy to me that they are encouraging developers to move business applications to that environment but do not have a database solution to offer.

    Well for business applications you'd hope you were using a central database, and not individual ones on every users' desktop.

  • Retro​Recursion

    , evildictait​or wrote

    There's even an entire fake directory structure in the Windows directory and the registry (C:\Windows\syswow64) which appears as C:\Windows\system32 to 32-bit apps just to maintain binary compatibility with old and crusty apps that aren't 64-bit aware.

    Understood. But then again, most of Microsoft's big tools are still 32-bit only. Consider Visual Studio and SQL Management Studio as examples. There are very good technical reasons why they remain 32-bit, not just because they:

    - are old and crusty

    - can't figure out how to maintain compatibility

    - refuse to break backward compatibility

    My point is that Microsoft goes to absurd lengths to make sure that an app you compile today will work 10 years down the line, no matter how much they change under the hood in Windows.

    I absolutely agree with you. I'm not worried about the desktop going away anytime soon. What I said was that I'm worried about the desktop area becoming deprecated and that there are already signs of it becoming legacy. I love the thought of moving forward, but please give me a path for doing so. The bridge to WinRT is not even close to being there yet. And using WPF to do anything remotely powerful puts you back on the desktop anyway.

    frankly if you're worried about the future-proofness of your apps, then look at WPF versus WinForms. 

    Yet another takeaway I had from Build is that WPF was not the suggested UI path moving forward. It's a choice, but not necessarily the one Microsoft is going to run with.

     don't believe everything you hear at Build.

    I'll try not to believe everything.  Big Smile

  • Retro​Recursion

    , blowdart wrote

    Well for business applications you'd hope you were using a central database, and not individual ones on every users' desktop.

    Using both actually for Smart Client apps. So you need to have a local copy just as Outlook does for us with OST files.

  • DCMonkey

    , blowdart wrote

    *snip*

    Well for business applications you'd hope you were using a central database, and not individual ones on every users' desktop.

    Well, you can't use that either unless you wrap that central database in a Web Services layer.

  • blowdart

    , DCMonkey wrote

    *snip*

    Well, you can't use that either unless you wrap that central database in a Web Services layer.

    Well. any web based facade, you don't have to use SOAP.

  • Deactivated User

    Comment removed at user's request.

  • evildictait​or

    , jinx101 wrote

    *snip*

    That's kind of presumptuous though.  I know they want people to live in the cloud to create residual income, but sometimes it makes sense to have a local database solution.  I'm not against the cloud or central databases but it's not a one size fits all world. 

    Who said the database needs to be "in the cloud"? It just shouldn't be on the same machine as your users.

    I don't ask my users to install Visual Studio, IIS or Windows Server 2012 on their boxes. I kind of think asking them to install SQL Server is similarly foolish - particularly since now you have to pay for 1 SQL server licence per user rather than 1 per organisation.

  • Deactivated User

    Comment removed at user's request.

  • DCMonkey

    , evildictait​or wrote

    *snip*

    Who said the database needs to be "in the cloud"? It just shouldn't be on the same machine as your users.

    I don't ask my users to install Visual Studio, IIS or Windows Server 2012 on their boxes. I kind of think asking them to install SQL Server is similarly foolish - particularly since now you have to pay for 1 SQL server licence per user rather than 1 per organisation.

    Care to point me to the client side libraries I can use to access that database from a Windows Store app?

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.