Thread: A New Reason to Hate Windows

Originally Posted by Neo1

That is nothing, i hooked up my SOs Windows Phone to my Windows 7 PC for the first time a couple of weeks ago. It started the usual 'Installing Device Drivers' procedure, but when it finished, i was asked to restart my computer for the changes to take effect. No, this was not on Windows 98, this was on Windows 7, but hang on, it gets better.

After rebooting, which is a 20 minute ceremony that requires a blood sacrifice and a special rain dance to be performed, on my current system, i was finally ready to go. I plug the phone back in, and a window pops up about downloading and installing Zune. I dismissed it and tried accessing the phones memory as i would any other flash drive or phone or whatever: No luck. After a bit of Google i realize that, to be able to use a Windows Phone as you would a thumb drive, you have to jump through hoops of fire and edit some registry keys and fumble with DLLs and all that jazz. So i plug the phone back in, and play along with the Zune installer for a while, this takes AN AGE to complete, and at this point im getting mildly irritated (read: fuming at the mouth). Lo and behold, the installation has finished, please restart your computer for the changes to take effect, at which point i decided to commit sepukku, just to make the pain stop.

This was with a WINDOWS phone on a WINDOWS machine. My own Android phone acts exactly like a thumb drive when i plug it in, and it's completely painless. I simply cannot fathom how Microsoft can make their own stuff work together in such a poor manner, when Google manages to make it quick and easy.

Sounds retarded. Just another proof of how Microsoft's products are horribly convulsed, have performance issues and generally have just horrible implementation and are buggy as hell. Not to mention they love to use complicated and deprecated technologies such as COM.

And ofcourse, Zune then claimed ownership of all my MP3 and WAV files, without ever asking me. To top it off it is a completely sloppy, slow and disfunctional piece of software, the only program i can think of that is equally disappointing is iTunes.

I'm sure there's alot of skilled programmers/developers at Microsoft, but there must be an equal amount of ........ty and clueless managers that simply have no idea what it is the users are looking for, so much bloat. Simply, staggering amounts of uselessness.

This is one of the reasons why Windows needs to change, and why I'm rooting for the new Metro API to take root and become the standard for the future.
(The UI sucks IMO; but the API itself is a huge leap of bounds from the old C API.)

Originally Posted by Fordy

Do a search on recent articles about Microsoft and the culture there. I'm sure they are not always accurate, but there's loads of quotes from ex-employees with axes to grind about "nothing gets the green-light unless its part of Windows or Office" and problems with team performance ratings etc...

Another good source is MiniMicrosoft, from an employee in the active.

Originally Posted by Elysia

This is one of the reasons why Windows needs to change, and why I'm rooting for the new Metro API to take root and become the standard for the future.
(The UI sucks IMO; but the API itself is a huge leap of bounds from the old C API.)

It's been quite a while since WinRT was first released. I'm still surprised this error still shows, on a programming forum of all places. WinRT is not a replacement of the WinAPI. Microsoft has stated this much more than once. If the WinRT is "leaps and bounds from the old C API", as you put it, this is because it doesn't even start to cover WinAPI scope. Try and write a device driver in C++/WRL or C++/CX.

Originally Posted by Mario F.

It's been quite a while since WinRT was first released. I'm still surprised this error still shows, on a programming forum of all places. WinRT is not a replacement of the WinAPI. Microsoft has stated this much more than once. If the WinRT is "leaps and bounds from the old C API", as you put it, this is because it doesn't even start to cover WinAPI scope. Try and write a device driver in C++/WRL or C++/CX.

I never said it would replace it. Yet, anyway.
Yes, it will not replace everything. It might replace desktop apps one day. Maybe then we won't have the issue that every program steals associations and pops up windows right in front of your face whenever they feel like it. That's good, right?
Everything has a transition, but if it's successful, then who knows? Perhaps we might code drivers in it one day. Obviously, until such a time (if it ever comes), C/C++ will still be used to write your drivers.

Originally Posted by Elysia

Yes, it will not replace everything. It might replace desktop apps one day. Maybe then we won't have the issue that every program steals associations and pops up windows right in front of your face whenever they feel like it. That's good, right?

Nope. Replacing Software Design Guidelines with an API is hardly a good thing. But we'll have this conversation again in a couple of years...

Originally Posted by Mario F.

Nope. Replacing Software Design Guidelines with an API is hardly a good thing. But we'll have this conversation again in a couple of years...

From a programmer perspective, perhaps. But from a user perspective it is a really, really good thing when you have hobby devs pushing out apps. Just look at Android, and today's Windows desktop apps. They're a prime example of what happens if you have guidelines in place instead of proper APIs.
Besides, I was referring to the fact that "maybe then we won't have the issue that every program steals associations and pops up windows right in front of your face whenever they feel like it." That kinda violates every guideline there is, if I have to guess (I haven't looked at the guidelines).

Originally Posted by novacain

I don't think you understand WinRT, which is no longer termed Metro (due to another company using the name).

WinRT is a COM based API and is built on the WIN32 API. So I fail to see how COM is depreciated, nor how WIN32 can be made redundant.

Personally I just use the right tool for the task at hand, regardless of my feelings towards the company that made it (and I find WIN32 and COM easy to use/understand).

I know it's not named Metro, but that doesn't matter. A name sticks. I like to call it Metro, and that's all.
WinRT may be built on COM and WIN32, but that doesn't change the fact that it's still inside a little isolated box. It's clean, it's modern, it's object-oriented, it's async by default, and just so much easier to use.
Compare that to COM and WIN32. They are both the absolute reverse. They are C API on a rich modern, flexible and huge platform. Hardly appropriate. No matter how much you try to pretty it up, it will still fall short to APIs built on languages that can express the flexibility and power of a modern platform where resources are not constraints (does not apply to drivers and kernels).
And no offence to you, but you've been using COM and WIN32 for a long time. You are like a guru there. Of course you find it easy. But other people will not.

Again, we stress the right tool for the job, and I agree with you. If I have a chance to use a high level language with good abstraction, I will use that. And that typically means WinRT or Metro over WIN32 and COM unless I absolutely have to use it, because WIN32 and COM are essentially C based APIs. They take a lot of code to do little things. They don't clean up (has to be done manually). It's so big, and so hard to grasp. That means it will become a niche, where most people will fail to grasp everything.
So again, if you understand COM and WIN32 well, then fine, go ahead and use it. It's fine.
But if it's a new programmer who do not understand these technologies well (which will oh so many), then clearly it is not the right tool for them. And if they can learn a similarly powerful tool in less time, why should they not do it?

Originally Posted by Elysia

WinRT may be built on COM and WIN32, but that doesn't change the fact that it's still inside a little isolated box. It's clean, it's modern, it's object-oriented, it's async by default, and just so much easier to use.

More confusion. But this time it wasn't your fault. Novacain lead you into it. WinRT is not built on Win32. It's a native API in its own right. ARM processors don't support the Win32 API, for instance. All they can rely on for windows-based application development is WinRT.

On Intel-based processors, WinRT sits alongside the Win32 API. Completely independent and not on top of Win32. It's however for most purposes a redundant API under Intel-based windows development. It brings nothing really new to the table with one notable exception; WinRT gives proper access to C++ development for the .Net platform, whereas the .Net Framework atop Win32 doesn't.

The price you pay is however a more limited access to Win32 functions and objects, limiting the scope of that which you can develop for Windows. Neither will WRL give you support for exception handling. HRESULT is the means by which you handle errors in WRL. Alternative you can go with a Microsoft extension to the C++ language; CX. But here you will have to contend yourself with an altered programming language with different syntax and semantics which most certainly won't reflect C++ standards evolution. And you still won't have full access to the Win32 API.

WinRT is however the first proper API since Win32. I'll give you that. A possible successor to the WinAPI, despite what Microsoft may say about it now. It's however meant to forever change the landscape of Windows development in a direction you may not appreciate. Since the .Net Framework back in 2000, Microsoft has been doing all it can to reduce C++ development on windows... better, to control and limit the language tendency to provide programmers ways in which they can shoot their own feet and Windows itself. It's essentially trying to rescue the Windows platform from bad programming habits, much like what Apple does with iOS development. Being that C++ is a generic programming language that cannot be at the service of a operating system vendor, the only way to achieve this is to either remove access to it (Apple way) or to induce programmers into removing it from their toolset by slowly undermining the programming language scope and reach (Microsoft way).

Originally Posted by Elysia

Not to mention they love to use complicated and deprecated technologies such as COM.
<snip>
I'm rooting for the new Metro API to take root and become the standard for the future.
(The UI sucks IMO; but the API itself is a huge leap of bounds from the old C API.)

I don't think you understand WinRT, which is no longer termed Metro (due to another company using the name).

WinRT is a COM based API and is built on the WIN32 API. So I fail to see how COM is depreciated, nor how WIN32 can be made redundant.

Personally I just use the right tool for the task at hand, regardless of my feelings towards the company that made it (and I find WIN32 and COM easy to use/understand).