Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Operating Systems Software Windows IT Technology

How Microsoft Dropped the Ball With Developers 814

cremou writes "As part of an Ars Technica series on how one developer migrated from Windows to OS X (and why), this second article concentrates on how Microsoft bungled the transition from XP to Vista. The author looks at some unfortunate decisions Microsoft made that have made Windows an unpleasant development platform. 'So Windows is just a disaster to write programs for. It's miserable. It's quite nice if you want to use the same techniques you learned 15 years ago and not bother to change how you do, well, anything, but for anyone else it's all pain... And it's not just third parties who suffer. It causes trouble for Microsoft, too. The code isn't just inconsistent and ugly on the outside; it's that way on the inside, too. There's a lot of software for Windows, a lot of business-critical software, that's not maintained any more. And that software is usually buggy. It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hard-coded locations, all sorts of things that it shouldn't do.'"
This discussion has been archived. No new comments can be posted.

How Microsoft Dropped the Ball With Developers

Comments Filter:
  • Re-runs (Score:0, Insightful)

    by Anonymous Coward on Monday May 05, 2008 @08:20PM (#23306548)
    Good God how many re-run articles do we have to endure on Slashdot? This flamebait type of article is every 5 minutes.

    Slashdot hates America, Religion and Microsoft. We get it already!
  • by dreamchaser ( 49529 ) on Monday May 05, 2008 @08:22PM (#23306574) Homepage Journal
    "It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hard-coded locations, all sorts of things that it shouldn't do."

    Those are basically programming errors, not problems with the API. Don't get me wrong, I find Win32 to be a pain in the ass sometimes, but this article just reeks of flamebait.
  • by clintp ( 5169 ) on Monday May 05, 2008 @08:41PM (#23306714)
    The False God of Backward Compatibility has Microsoft by the short hairs. Even new programming environments like .Net have Win32, Win16, and DOS lurking right around the corner. There's no fresh start anywhere in the Microsoft environment, everything reeks of DOS.

    Which would have been find if DOS (Win16, Win32, etc..) were a multi-platform, extensible OS to begin with -- but it wasn't. It was a quick hack that lives on and on.

    I'm a developer that works primarily in Windows, with 15 years of heavy-hitting Unix programming experience behind me.
  • by Ulfalizer ( 881975 ) on Monday May 05, 2008 @08:41PM (#23306716)
    I think you missed the point.

    The problem is that many major legacy applications depend on undocumented behavior because they make sloppy use of the Windows API (e.g. by assuming that a particular function will not segfault when passed a bad argument). For those to keep working, newer revisions of the API implementation must have the same undocumented behavior, which causes a maintenance nightmare.
  • by 0123456 ( 636235 ) on Monday May 05, 2008 @08:42PM (#23306726)
    "Those are basically programming errors, not problems with the API."

    I think you missed the point. For the sake of backwards compatibility, Microsoft supports applications which do all these things, and drags all the associated crap into future versions of Windows so they still run.

    For that matter, so do hardware developers: back when I was writing drivers for Windows I had to deliberately put bugs in our code to support applications which only worked because of bugs in the Microsoft versions of the drivers and would crash if we didn't replicate those bugs ourselves. We also spent weeks working around abuse of the API by a certain big computer company that can't program PCs worth a damn (or even, apparently, read API documentation).
  • Re:Long Answer? (Score:2, Insightful)

    by Jeremiah Cornelius ( 137 ) * on Monday May 05, 2008 @08:48PM (#23306776) Homepage Journal
    You gotta admit, he has a point and illustrates it pretty well.
  • by Anonymous Coward on Monday May 05, 2008 @08:49PM (#23306794)
    What exactly is this guy recommending? He trumpets Apple for overhauling their platform and releasing a rapid succession of new OSes in order to advance the platform, which retaining absolutely no backwards compatibility. Meanwhile, Microsoft releases new runtimes for it's existing platforms, not requiring the purchase of a new OS, meanwhile retaining nearly full legacy support. How many 10 year old applications can you run on a new Macintosh right now, without relying on third-party emulators? You can count them on no hands. However, you can run the majority of 10, 15 and 20 year old Windows applications on Windows Vista.

    And to claim that .NET is hobbled due to Win32 is just silly. He targets WinForms specifically, which, sure, is a wrapper around Win32. But to claim that you need to know Win32 to program WinForms is just ludicrous. It makes me think that he's never programmed for either platform. WinForms hides the details of Win32 a great deal, and it's very rare to ever have to rely on platform invoke calls. And if WinForms is such a problem, why not use Gtk#? Or WPF? .NET is not one monotonous entity, and there are several UI libraries.

    He complains that the Win32 API for finding a file size requires you to deal with two 32-bit values, stating that on Win64 that it should return a 64-bit value instead. Well, if he wasn't such an idiot, he could use the newer version of that same API which does return a 64-bit value, on Win32 and Win64.

    All this dumb shit seems to do is claim that the platform should be constantly broken, because that would be the most convenient for him. If you think that the developer experience on Windows is bad then I posit that you've never programmed before, for any platform, ever. Either that or you are a fucking retard who has failed so badly as trying to hack together code that you're only possible saving grace is to write an inflammatory article and try to eek a living out of click ads.

    It's actually kind of funny watching retards like this rant. They have no clue what they're talking about yet they are so sure that the problem must be something other than themselves. Fuckwits like this make it much easier for me to find work cleaning up after their garbage, and make a small fortune doing so.
  • Inconsistencies (Score:2, Insightful)

    by neokushan ( 932374 ) on Monday May 05, 2008 @08:58PM (#23306868)
    I'm not exactly what you'd call a hardcore developer (I make games, not Applications), nor am I in any way familiar with developing on Mac OS X, but this article definitely seemed pretty inconsistent.

    For those of you who CBA to RTFA, FYI here's a small summary of it:

    It starts off saying there's basically 3 kinds of developers, 2 kinds that don't care what the code does as long as it works and 1 kind that cares deeply about "doing it right". It then says that this kind of developer doesn't matter because it's all hobbyists anyway. It says the first 2 kinds just want to get the job done and don't particularly want to or care to learn anything new to do it.

    Next, the article has a complete bitchfest about the .Net framework. Nothing new there, but it's main complaint is that it's meant to be a shiny, new API, but it's roots are still buried deep within the old API's of Win32.

    Then it bitches a bit about said Win32 API, but it's main point is that you don't learn anything new, it's just the same thing you've been doing "for the last 15 years", as the summary points out.

    Then, curiously, it states that this suits the first two kinds of developer just fine and this is where I get a bit confused. It's trying to bitch about the framework, it's trying to point out how it's flawed, but all it's really done is point out that it works just fine for the only developers that (in the article's own words) "matter".

    This leads me to the conclusion that the author really was just trying to start a flame war but instead of coming up with a reasonable argument (Of which, on the Windows platform, there are many - just like any other), he sort of just throws in a few keywords, rambles on without re-reading what he's wrote and then finishes it off by bitching about some of the quirks of the platform, quirks that are only there because people REFUSE to do anything different than what they've been doing for the last 15 years.

    In other words, he's blaming Microsoft for catering to lazy, underpaid developers.

    Does that make them the bad guys? Not if you've got a multi-million $$$ business to run and want to keep costs to a minimum so you can give yourself a big raise at the end of the year.
  • by Kalriath ( 849904 ) * on Monday May 05, 2008 @08:59PM (#23306876)
    Are you mad? The compiler itself is free with the platform (.NET Framework in its bin folder has programs called CSC and VBC. Run them sometime). The documentation is free to access. Visual Studio itself can be bought and paid for at anywhere between $500 and $1000 depending on the edition you want.

    MSDN is just an added bonus because it gives access to every development oriented Microsoft product in existence, including Operating Systems, Servers, and Office. That sort of stuff for that price ($1000 or so I believe) is pretty good really.

    I should probably also add that you can also write Windows apps for free using compilers like GCC and cygwin or similar, and IDEs like Eclipse - if you don't want to use Microsoft tools. It isn't necessary and never has been to use Visual Studio to make Windows apps.

    Or to sum up the parent poster... "troll troll troll, troll troll troll troll".
  • by pebs ( 654334 ) on Monday May 05, 2008 @09:02PM (#23306908) Homepage
    nothing comes close to Visual Studio in terms of functionality, quality, and just being solid

    Are you using the same Visual Studio I am? Because the one I use may have some decent functionality that you'd expect from an IDE, despite being crippled by a lousy interface (with some exceptions, they do some things very nicely). But when you're used to using Eclipse, Visual Studio feels like a cheap, buggy toy. I use both at my day job. I would never use Visual Studio unless paid to do so. Eclipse I use for fun on my hobby projects.

    Yes, there are much worse IDE's than Visual Studio, but that doesn't mean its good.
  • by buss_error ( 142273 ) on Monday May 05, 2008 @09:08PM (#23306968) Homepage Journal
    Back before my current gig, I was a software developer for companies that hired me to do their work and for several packages I wrote for my own profit. This story comes from the programs I developed for my own profit.

    Because the software I wrote was also licensed for source code if the user wanted it, I picked Visual Basic as the platform to use. I wanted to use Visual C, but you could more easly find programmers that could get by in Visual Basic than VC. I should have picked VC rather than VB for a lot of reasons, the main one being that if you had experience in VC, you were at least likely not to be a total idiot. Not so with VB. I found that VB programmers were idiots at the approximate rate of 7:10, while VC programmers were likely to be idiots at an estimated 1:10 ratio... which isn't to say that all VB programmers were idiots, only that they were cheaper labor, and therefore less likely to have a solid background in programming logic.

    That said, we'll focus only on my own development problems, just so we are dealing with only one (possible) idiot... me. I started out with VB 2.x. The upgrade to 3.x went fine, with very few problems. When 4.0 came out, I found I had to rewrite about 20% of my code. Sure, there were conversion programs, but they didn't quite fit in with exactly what I wanted the program to do. It'd get it about 90% right, but then I'd have to slog through the rest of the automated code to correct that last 10%. It was faster to discard that code and re-write it.

    Then 5.x came out. Only about 50% of my code still worked. And again, the automated process to "ease" transisition left something to be desired. When Visual Studio 6.0 came out, it was a nightmare. only 20% of the code ported. At that point, I sent the 5.x code out to all the people that bought the program (with source or not), and told them that the code was now moribund, I would not be maintaining it, and that I was releaseing the source code to the public domain (5 floppies included). As I recall, that was about 1998-1999 or so.

    As late as March 2008, I've been contacted about the code. Of course, it's morphed far past anything I'd written, and I could only help with the general business case logic involved, not the actual code. But having to deal once again with Microsoft development tools, one would have to offer me far, far more money than it would be worth. No, I'm done with Microsoft "development" games. I'm done with school yard bullies trying to take my lunch money. I'm done, PERIOD, with closed source, whenever I have a choice.
  • by 0123456 ( 636235 ) on Monday May 05, 2008 @09:09PM (#23306972)
    Pretty much; if they stop supporting old bugs, a lot of old software will break. I'm sure I found an old Windows 3.1 bug in XP some time back, but I can't remember what it was (something to do with driver installation, I think).

    Linux, in comparison, provides a fair amount of backwards compatibility, but doesn't have to overly worry because most software comes in source form and can be fixed when a kernel or library change breaks it. Windows doesn't have that option.
  • by larry bagina ( 561269 ) on Monday May 05, 2008 @09:13PM (#23307010) Journal
    My understanding was that they didn't expect much of the PC market, so they threw together a bunch of cheap parts from other vendors and stamped their name on it. Based on their Apple II CP/M card, they asked MicroSoft for an OS instead of buying or writing one.
  • by nojomofo ( 123944 ) on Monday May 05, 2008 @09:20PM (#23307068) Homepage
    Holy shit, you've got to be kidding me! Even VS 2008 needs Resharper to even be close to Eclipse in functionality. Have you ever used a different IDE?
  • by Coryoth ( 254751 ) on Monday May 05, 2008 @09:20PM (#23307070) Homepage Journal
    One of the nice things from this article was actually this nice screenshot [arstechnica.com] of a selection of current versions of MS software running on Vista. The thing to notice is that not a single one of those applications has a GUI the same as any of the others. There are different toolkits, completely different look and feel, some have menus, some don't; it's a horrible, horrible mess. And yet despite that, we still get people complaining about GNOME vs. KDE and the clash of different toolkits and how that's what is holding Linux back. You can run GNOME and KDE apps side by side and, while they'll have differences, they'll sit together far more elegantly than the mishmash that is Windows. I think I'll have bookmark that screenshot so I can bring it up the next time a Windows fanboy starts decrying the excessive number of GUI toolkits on Linux.
  • by abes ( 82351 ) on Monday May 05, 2008 @09:22PM (#23307090) Homepage
    I'm not big on the M$ love. I'm a mac/linux proponent. However, I think that M$'s current problem with a really horrible API (I'm saying this having programmed for win32, GTK, QT, WX, and Cocoa) isn't an easy to solve problem.

    They could pull an Apple, and completely redo their windowing system. Apple benefited from using NeXT's system, which was well thought out, uses a language well suited to windowing systems (objective-c), and could be altered based on previous user experience.

    However, in doing so they would lose all compatibility they current have. Keeping compatibility, even if it creates a developer's nightmare, is in the end what keeps them on top of the market.

    That is not to say it's not impossible for them to do so. Apple did provide a virtual machine to run old OS9 software with the first releases of OS X. However, since both Mac and Linux machines also have the same options (currently running Parallels on my machine), it would still take the clear advantage M$ has in the market away.

    It's not clear whether their bad API spells the eventual doom of the company. The more pragmatic developers will still value making products that more people can use over writing nice looking code. Additionally, wrapper libraries, such as WxWidgets or Qt can help hide much of the ugliness.
  • The problem is that many major legacy applications depend on undocumented behavior because they make sloppy use of the Windows API (e.g. by assuming that a particular function will not segfault when passed a bad argument). For those to keep working, newer revisions of the API implementation must have the same undocumented behavior, which causes a maintenance nightmare.

    So, you problem is that programmers make use of undocumented API calls. While "undocumented" does not always equal "unsupported", using them is just plain stupid. Whether it is Windows, Linux, MS-DOS, DR-DOS, OSux using the system in an undocumented/unsupported way is well, U N S U P P O R T E D. Don't blame the OS or the those that coded it, blame those that wrote against the API in an unsupported way.

    RTFA turns out to be a effort in slogging through another of the author's attempts to explain why anyone on Windows is just benighted. He blames HIS short comings on the OS.

  • by Anonymous Coward on Monday May 05, 2008 @09:29PM (#23307132)
    People seem to be missing this particular point. He's not bashing Microsoft for third parties writing poor software. He's bashing them for accepting it, making it easy for them to screw up (or hard not to screw up), and never taking decent steps forward for fear of breaking third party crapware.
  • by daemonenwind ( 178848 ) on Monday May 05, 2008 @09:34PM (#23307160)
    It's not a false god, not when you're coding for a business that has to meet both regulators and profitability expectations.

    Code written for Windows 95/NT (back in 1996) still works today on the Windows platform. 12 years later.

    Try that with System 7 code on OS X.

    Yes, this is part of why writing business-logic code sucks. You seldom get to just re-write anything to be really, truly good instead of something perennially built-upon and increasingly hacked-together. No one will pay for a change that doesn't deliver "business value". (And no, greater stability/performance is almost never enough, as that argument usually demands an associated headcount reduction) But at least the app still works and can continue to deliver. And since some will doubt, yes, I do maintain/enhance such code.

    The market speaks - this sort of backwards compatibility is a conscious choice by MS, and it does sell their OS. Not concidentially, it also sells mainframes and *UX systems. And I'm convinced it's one of the big reasons Apple isn't bigger in the corporate world. Steve's demands for newer/better/faster totally supplanting the old are well known, and rightly feared.
  • Re:Long Answer? (Score:3, Insightful)

    by RiotingPacifist ( 1228016 ) on Monday May 05, 2008 @09:38PM (#23307200)
    Does he have a point though?
    I think the giveaway is when he says a screen shot is worth a thousand words, then his screen shot is of vista with the taskbar at the top, Im not saying nobody has the taskbar at the top but its just one of many signs that hes a fan of apple.

    Im no programmer but the article seams short on facts & details and high on ms bashing & skimming.
    Is the article right or is it just well presented trolling?
  • by IdeaMan ( 216340 ) on Monday May 05, 2008 @09:41PM (#23307230) Homepage Journal
    Same as when IBM jumped the shark...

    When they tried to force a product down the consumers throat that there was no perceived need for, which could be replaced by products that were not IP locked.

    For you younguns IBM's was called Microchannel.
  • Re:Long Answer? (Score:5, Insightful)

    by Winckle ( 870180 ) <mark&winckle,co,uk> on Monday May 05, 2008 @09:42PM (#23307240) Homepage
    I have my taskbar at the top, because it effectively reverses the order of the start menu. This makes shutdown the bottom option, which is where it should be, as i use it precisely once per session.
  • by icepick72 ( 834363 ) on Monday May 05, 2008 @09:43PM (#23307246)
    Because some classes are static or sealed does not mean the CLR doesn't support full OO features. I known you recognize that but some people reading your post might misinterpret it so I'm clarifying. What it means is some class designers made some arguably bad decisions about how to allow their classes to be used. Sometimes the class designer is Microsoft. But I'm there with you buddy. If only I could count the number of times I've cursed a class designer because they didn't let me instance it. In the cases you mentioned I noticed you didn't talk about System.IO.FileInfo or System.IO.DirectoryInfo classes which are the instanceable counterparts of the static System.IO.File or System.IO.Directory classes you listed. Use the static classes for speed against multiple files and directories but if you want an instance wrapper around a file or directory you can easily do that with those other classes. As for the P/Invokes, well... I don't have a great answer except it's not a perfect world ... yet. .NET is a strong leap towards there.
  • by overbaud ( 964858 ) on Monday May 05, 2008 @09:47PM (#23307282)
    "If a company has some business-critical custom application written in Visual Basic 6, that company isn't going to roll out Linux to its desktops; it's trapped on Windows."

    Actually they could host it within citrix or similiar and rollout to the desktops. They are not locked into windows on the desktop.

    "They're too demanding anyway. They're the ones who care about their tools and get upset when an API is badly designed. They're the ones who notice the inconsistencies and omissions and gripe about them."

    Or maybe they accept that there is no such thing as the perfect piece of software. Maybe they understand that the software in question a lot of the time is there to support business and sometimes business requirements out weigh technical 'perfection'. I accept it as a fact of life... like taxes blogging about it won't change a thing.

    "For example, there's a function called OpenFile. OpenFile was a Win16 function. It opens files, obviously enough. In Win32 it was deprecated--kept in, to allow 16-bit apps to be ported to Win32 more easily, but deprecated all the same."

    And as a good developer you won't use it. Maybe a bad developer will but a bad developer will write bad code regardless of how many things you put in place to stop them. A developer should be able to use his discretion as to using this or not, taking into account his particular circumstances. Maybe it should be used for a quick dirty port while version '2.0' is under development. 'Get it in, get it running, minimise the business impact and we'll address these issues next major release' is something that commonly gets thrown around in enterprise by management... you know they guys that are paying for your services.

    But if you use the same API in 64-bit Windows, it still gives you the pair of numbers, rather than just a nice simple 64-bit number. While this made some kind of sense on 32-bit Windows, it makes no sense at all on 64-bit Windows, since 64-bit Windows can, by definition, use 64-bit numbers.

    This and other points in the article are such small non issues and are just gripes. Would it be nice to get 1x64 number? Yes. Does it make no sense? No. Looking deeper at things like reducing time to port 32bit to 64bit and associated costs in developer time/money it makes sense. I can happily live with it.

    In 32-bit Windows, it was called system32. In 64-bit Windows it's called, er, system32 again. Because although there's an API call that programs can make to find out the name of the folder, there are enough programs that don't bother using it and just blindly assume that it's called system32.

    Again... you can't stop bad programmers (a lot being 3rd parties) from making dumb mistakes... but you can try and reduce the impact. You can bet there are those purists just like the article author inside MS that hate this as well. But in the interest of having this work a decision was made, and i suspect not for MS's benefit. Again just live with it.

    For example, dialog boxes in Windows have traditionally been poorly designed, because their buttons are given generic labels like "Yes" and "No," or "OK" and "Cancel,"

    Microsoft have been going on about this for ages since 2001 actually. http://msdn.microsoft.com/en-us/library/ms997506.aspx [microsoft.com]

    If you take the ranting and raving out of the article it has very little of value. If Mac or *nix had greater market share then we would see more bad software and API's in those environments as well. As it is some of the open source code I have seen is terrible. There is no way to prevent these issues economically, good programmers just accept them, code around them and move forward.

  • by 644bd346996 ( 1012333 ) on Monday May 05, 2008 @09:49PM (#23307304)
    15 years ago, object oriented programming was still catching on, and the Pentium was brand-new. Computers were slow, people had about as much RAM as modern CPUs have cache. The Windows operating systems of the time were just starting to support 32-bit features. Pre-emptive multitasking was still 2 years away.

    When it comes to using the extra power of modern hardware, it is easy to say "I want it to make everything 10 times faster". On the other hand, you could use that power to run a python interpreter, and make things 10 times easier for the programmer. Both are perfectly good uses of the more advanced hardware. But the latter is where you'll see the really innovative apps showing up. That's what Microsoft is missing out on when their platform still doesn't let you ignore the nitty-gritty details that you couldn't afford to ignore 15 years ago.
  • by fimbulvetr ( 598306 ) on Monday May 05, 2008 @09:50PM (#23307322)
    Maybe the point was that MS fosters bad programming by keeping legacy API calls around indefintely, whilst other systems do not. I'm the last guy to ever go pro-apple on /., having "been there, done that", but he really does have a point. MS is afraid to deprecate bad ways in favor of keeping some minor share of customers happy.

    While this has short term benefits, the long term imposes a hefty penalty, the same penalty MS (and some of its developers) is paying now.
  • Re:Long Answer? (Score:5, Insightful)

    by murdocj ( 543661 ) on Monday May 05, 2008 @10:02PM (#23307426)
    He has an axe to grind, but I'm not sure he has a point. For example, he talks about how .Net was supposed to insulate you from the vagaries of the Win32 interface,but failed. Then he talks about how the Win32 API returns the length of a file as two 32 values that have to be combined, instead of a 64 bit value. The part he leaves out is that .Net's system.IO.FileInfo does exactly what he wants... it returns the file length as a long 64 bit value. So why bring up the old 32 bit interface when you don't have to deal with it anymore? If that's the best he can do, his argument is in trouble.
  • Try VMware Worstation (or ESX if you have money to burn). Install OS in VM, register with MSDN. Snapshot; backup VM to media. Develop, restore snapshot.
    And, you saved yourself the hassle of reinstalling the OS again.
    And, you are assured of having the exact same development base OS every time.
  • by Concerned Onlooker ( 473481 ) on Monday May 05, 2008 @10:17PM (#23307534) Homepage Journal
    "He trumpets Apple for overhauling their platform and releasing a rapid succession of new OSes in order to advance the platform, which retaining absolutely no backwards compatibility."

    This is a false statement. Or at best misleading. Yes, Apple did finally ditch OS 9 after many years of offering backwards compatibility. Their succession of OSes, or OS X as some of us call it, are all backward compatible. Unless I'm mistaking your definition of backward compatible.

    Apple's decision to make a break with their old OS was a good one, and I'm sure just about anyone would agree with that. I liken it to when the camera manufacturer Canon abandoned their old twist-lock lens mounts in favor of the electro-mechanical mount. That allowed them to develop the best autofocus lenses on the market and to finally overtake Nikon in a big way, whom they'd been playing second fiddle to since forever.
  • Yes, even HAVING undocumented API's is bad as well.

    I thought we discussed this when Apple did it? Undocumented APIs are there for the use of operating system developers and other people who feel the need to tickle the operating system at a low enough level to fool it into doing things that it was never intended to do for you. This is your prerogative; it's possible to sniff through the structure of the binaries to find new functions, and it's possible to debug functions to see what they're calling, so no one can really stop you anyway.

    At the same time, being upset when they stop functioning correctly is the mark of a whiny idiot, because let's face it, they're undocumented. If you want that functionality exposed, by all means, cry to the OS vendor. Or, you know, you could support open source and/or free software and work with an environment in which you have all the source code and can at least make relatively responsible use of the undocumented functions, and if you are feeling froggy, even submit patches which express this functionality consistently with a documented API.

    Seriously though, undocumented functions are par for the course. If the functions are never intended to be used by anything other than the operating system, and the functionality is expressed through the OS in some fashion (use of undocumented APIs in Win32 has often been done to work around a bug) then there's really no problem. The portions of the OS that need to be changed when the libraries change can be changed in such a situation (and hopefully will fail tests if someone doesn't think to do it beforehand.)

  • by Homburg ( 213427 ) on Monday May 05, 2008 @10:25PM (#23307602) Homepage
    "Vista and Office 2007 moving away from word lists (MENUS) is the right direction."

    Quite right. The last thing I want in my word processor is words.

  • Half-baked article (Score:2, Insightful)

    by flnca ( 1022891 ) on Monday May 05, 2008 @10:46PM (#23307762) Journal
    I can only say the featured article appears half-baked to me, and it's comical how Apple users always bring up GUI design issues, as if that was the most important thing in the world.

    I tried Apple's XCode IDE last year, and I was put off by it's total lack of good UI design. XCode's editor cannot be customized, has a hair-line thin text cursor that is barely visible and a weird keyboard layout that originated somewhere in the 80ies (on MacOS and Amiga systems), that is totally uncomfortable to use nowadays. No mention of this in the article.

    Also, the article mentions minor aspects of perceived Win32 and .NET flaws, when in fact the flaws are much bigger, and the short examples only give the impression that he has looked at them briefly at best. No mention of the GetFileSizeEx() function, for instance. The old GetFileSize() API [microsoft.com] was for NT 4 and Windows 95 and previous OSes (note how the older OSes have already been dropped from the platform compatibility list). GetFileSizeEx() API [microsoft.com] was new for Windows 2000, which is already over 8 years old.

    Also, as has already been mentioned here, the article omits WPF [microsoft.com], which is a fairly important development by Microsoft. It enables programmers to create 3D applications in XML! I tried it a number of times and it seems pretty good to me.

    But the core statements about .NET and Win32 in that article are true. The .NET framework has (or rather, had, because we're talking .NET Framework 3.5 now) some very weak concepts. Also, the documentation team is far behind with the documentation; there's a lot to be left desired in that area. The Win32 API is much better documented still. If you develop your own controls, you might run into problems with .NET, because native timers and carets are not directly supported, for instance (Win32 API calls are required for that).

    I've been developing mostly for Windows in the past 13 years, with the occasional UN*X and OS/2 thrown in, and I still find that all of them lack some of the flexibility and power of an AmigaOS, which I used and programmed on from 1986 to 2001. THAT would be the ideal development platform, because it allows unrestricted programming; sadly, Commodore folded in 1994, and not much good happened since then. GUI and development guidelines were followed by Amiga programmers voluntarily, out of interoperability concerns. All major (and many minor) applications had an ARexx scripting interface, for instance. GUI guidelines were often followed also, because the guideline manual (or chapter, in the older RKMs) was thin and easy to read. BTW, the Tool Info feature of the Workbench is still unmatched today. A user could easily configure their applications to their desires, or even configure the entire user experience to their liking, booting up Commodities (which were similar to Windows Services, except they supported user interfaces) as needed, that even sometimes changed how individual controls behaved. Tools like MagicMenu changed the entire menu system for all applications, and so on. Virtual memory and memory protection could be added by the user, and so on. There's much that needs to be said about the Amiga platform, that made it ideal for developers. For instance, the non-copying message system that was easily used to communicate between threads, making multithreaded applications easy, and that also served as an IPC mechanism.

    I can tell you: On all so-called "modern platforms", everything is much, much more complicated than it needs to be. OS implementors only have to look at the things that have already existed, instead of reinventing the triangle-shaped wheel over and over. ;-)
  • Re:Long Answer? (Score:3, Insightful)

    by Merusdraconis ( 730732 ) on Monday May 05, 2008 @10:50PM (#23307778) Homepage
    FTA:

    "Regular updates to the OS keep developers on the upgrade treadmill; they work to make their applications fit in with the latest and greatest release, leveraging whatever new bells and whistles it provides, further improving the software ecosystem."

    As we see from the Windows and Mac OS (pre-X) ecosystems, this is completely false. Developers are loathe to change custom-written code that they know works in order to implement some kind of link to the OS; and in many cases they'll let old versions of their program stop working when a new version comes out and replaces it.

    Microsoft knew what they were getting into with Vista's backwards incompatibilities, and oh lordie how people complained. Consumers (and, it seems, developers, who should know better) often blame Microsoft when their new product breaks backwards compatibility, even if it's the program's fault for doing it the wrong way. For the most part, Windows developers are pragmatic, which is why they're working on Windows (the biggest install base), so whatever works is more or less good enough.

    I will delight at what happens if Linux ever manages to get majority market share and it starts getting some of the less-skilled pragmatic developers.
  • Re:Long Answer? (Score:5, Insightful)

    by Anonymous Coward on Monday May 05, 2008 @11:03PM (#23307892)

    Then he talks about how the Win32 API returns the length of a file as two 32 values that have to be combined, instead of a 64 bit value. The part he leaves out is that .Net's system.IO.FileInfo does exactly what he wants
    This was a complaint about Win64. He had different specific complaints about .NET.

    If that's the best he can do, his argument is in trouble.
    If you can't even read his argument without getting mixed up, then your future is in trouble. (OTOH you have a bright future as a Slashdot poster. Not reading TFA is henceforth passé; reading it and getting it entirely wrong is the new standard.)
  • by Anonymous Coward on Monday May 05, 2008 @11:10PM (#23307936)

    So for 'real developers' like Adobe (OS X) is a failure, and has failed paths."

    This brings up the horrid Carbon/Cocoa
    Dear Mr. Warthog, (thats you TheNetAvenger) If you don't read anything else I've written read this. One of the main points of this article was to detail how maintaining backwards compatibility can actually hurt a platform and its developers instead of help them.

    Apple and Microsoft are antitheses of each other in this regard. Apple has forced developers to move forward, kicking and screaming, over and over again, while maintaining a reasonable degree of backwards compatibility each step of the way, while Microsoft has to remain compatible to a million different quirks.

    In the case of Apple, this includes two architecture changes, Moto 48xxx -> PPC -> x86, and a complete overhaul of their original API set, that became carbon, and the platform for the future based on objective C (and java at the beginning, but developers have spoken on that, and nobody sans Azureus wants it) that is cocoa.

    I personally find it amazing that on a Intel Mac today you can (1) run programs that were originally coded for Mac System 7 running on Moto 48xxx with a moderate degree of work, and (2) run carbonized programs that were originally coded for OX X PPC on intel through emulation without any recode, and very little performance hit.

    With regards to your claims about Adobe, I suggest you put your foot down, and next time do your homework.

    Thank you Madonna. LoL

    Author doesn't realize Microsoft and IBM wrote most of the GUI and UI guidelines that OS X even uses today.
    I'm not going to argue who came up with the idea first, as it is completely irrelevant. As the author of the article clearly points out, what is important is now the guidelines themselves, but how well a company implements them. The author also clearly demonstrates how Microsoft is decade behind Apple in this regard, but is making an effort with Vista.

    These claims are fully supported, you must be a blind ignorant fool not to see this.

    The author then jumps into UI consistency with dialog wording, and doesn't mention OS Xs lack of keyboard support.
    Oh you did see his support, you just choose to ignore it, how convenient. You then go on to provide further evidence of your ignorance by stating that OS X has no keyboard support???

    Please do enlighten us, what is this device that I am typing on right now called??? OH yeah, a keyboard, DOH!!!

    Office 2007 is a new direction in GUI paradigms, and is WELL accepted in the business world.
    Perhaps the business world of borg cubes, but most of us here on planet earth find Office 2007 a product with interesting ideas, but very much so confusing for reasons author clearly demonstrates in his article.

    You sir, are a warthog faced buffoon.

  • by HeroreV ( 869368 ) on Monday May 05, 2008 @11:17PM (#23308016) Homepage
    What languages do you use with Eclipse? Just Java? Because everything else I've tried with Eclipse totally sucked.
  • by fractoid ( 1076465 ) on Monday May 05, 2008 @11:19PM (#23308022) Homepage

    MS is afraid to deprecate bad ways in favor of keeping some minor share of customers happy.
    This is true, but remember that when you sum up the minor share of customers that's made happy by each of these legacy APIs, you end up with a large number of developers. A very large number.
  • Re:Long Answer? (Score:5, Insightful)

    by dcam ( 615646 ) <david.uberconcept@com> on Monday May 05, 2008 @11:34PM (#23308122) Homepage
    Everything I have read and heard about Microsoft suggests that they are cowboys.

    Code first, design later. For example, I note with interest the amount of pain involved in trying to provide server protocol documentation for the EU. Some of the foot dragging is deliberate but some of it is that they don't have quality internal documentation.

    There is a severe lack of direction and leadership at Microsoft. They are just not forward planning. As a result they are tearing themselves to pieces, doing the same work again and again.
  • To make it more amusing those third party APIs slog through the win32 API hell so you don't have to.

    I think that's why Microsoft is afraid of breaking the old APIs. Once you have to go through the pain of porting to a new API why not just go cross platform?
  • Re:Long Answer? (Score:5, Insightful)

    by thetoadwarrior ( 1268702 ) on Monday May 05, 2008 @11:44PM (#23308186) Homepage

    Im no programmer but the article seams short on facts & details and high on ms bashing & skimming. Is the article right or is it just well presented trolling?
    How can you say it seems to lack info when you're not even a programmer. For anyone who has done programming between good languages and MS languages will know he's spot on and it's been well documented that MS went back on their word to build a .Net based OS that started fresh.

    The problem is they know a lot of people aren't happy with Windows but it runs all their programs. Once the scrap that backwards compatibility and build something solid, despite the fact it may be their best OS ever, it's on a level playing field with the rest which means people have to find an alternative to their old programs and they might just pick something that isn't Windows and MS isn't having that.
  • Re:Long Answer? (Score:5, Insightful)

    by CodeBuster ( 516420 ) on Monday May 05, 2008 @11:52PM (#23308230)

    The argument that .NET is limited by the attempt to be simplistic is asinine
    I agree. It sounds to me like this guy used .NET for a year or so around 2002 when it was brand new and then left and hasn't looked again for the last six (6) years. He is the first person that I have heard accuse .NET of being "too simplistic". The .NET class library (and Java class library as well) is the definition of everything and the kitchen sink. These are extremly powerful languages and libraries that are if anything too complex.

    Before I even get into the technical components of his argument, if he's trying to say that Java is better in this area, then he needs to get his eyes checked.
    Again, I totally agree. The .NET Framework class libraries and the C# language are the definition of "The Right Way" to organize and structure code. They are technically sophisticated, architecturally beautiful, and make use of all of the best ideas at the culmination of nearly three (3) decades of object oriented programming theory and software engineering. If he is going to criticize .NET for its "lack of capability" then he is basically saying that Java is crap too, because .NET borrowed heavily from Java which in turn borrowed heavily from C++, smalltalk, and all the way back through C to Algol 60.

    portable across environments, but that's not what .NET development is being used for
    It is supported and in the future it will become more and more common. The great innovation on the part of .NET was the common runtime type description language and metadata in addition to the common language assembly. This is what allows different programming languages to fully share types across libraries compiled from different source languages (including cross langague debugging). This was the feature that Java was missing and this is a major reason why .NET is so popular, it has the potential to end the "my programming language is better than yours" debate because the common types and assembly make the argument irrelevant. Use C# or use VB.NET or use Eiffel or whatever other language you want.

    I can say with experience that .NET is very powerful and can be very pleasant to work with.
    I have been using .NET for six (6) years now and I can honestly say that it has fulfilled all of my expectations with very few dissapointments and it is improving substantially with each subsequent version. I know that I sound like a hopeless fanboy, but .NET really is a pleasure to work with, especially given the breadth and depth of the libraries and languages with a tool for every job and every job done with the right tool.

    I honestly think that .NET is a crowning achievement of theirs.
    Although it probably doesn't hold much water with the Slashdot crowd, I think that it is fair to say that .NET is the best thing ever to come out of Microsoft, even though it wasn't a completely original idea (but how many completely original ideas have there been in computer science anyway? Everyone benefits from the work of predecessors and ones who have come before us).
  • Re:Long Answer? (Score:3, Insightful)

    by try_anything ( 880404 ) on Monday May 05, 2008 @11:55PM (#23308244)

    He states several problems with the UI capabilities of .NET. Before I even get into the technical components of his argument, if he's trying to say that Java is better in this area
    He's not. He said that Java provides a better-designed API based on simpler, cleaner concepts that are easier to learn, whereas there's a bunch of .NET functionality that has funny exceptions because of Win32. Swing isn't pretty to look at, but he is correct that it has a clean conceptual foundation, even despite being built on top of an earlier, abortive attempt at a GUI API, AWT. As a Swing programmer, you don't have to deal with redundant Swing and AWT functionality. (It's there, but you can ignore it at no cost to your understanding.) The parts of AWT that are required for Swing are simple, easy to understand, and not redundant with Swing functionality.

    not happy with with the windows UI standards? Everyone else seems to be.
    "Happy with" and "stuck with" are two different things. Microsoft is screwing itself with the lack of uniformity in Windows. Microsoft's second-best asset (after developers, developers, developers) is the tendency of first-generation computer users to shit their pants when presented with minor look and feel variations. After Microsoft conditions users to expect a different look and feel for every new application they learn, normal users will be capable of switching between platforms without any problem. Then it will be a lot easier for businesses to use open-source operating systems to save money or to take advantage of an application that isn't available on Windows.
  • Re:Long Answer? (Score:3, Insightful)

    by LaskoVortex ( 1153471 ) on Tuesday May 06, 2008 @12:11AM (#23308346)

    Yup.

    Your link is all the more profound when one realizes that 90% of the posts on this thread are from defensive windows programmers. So, my question is, whence the hostility, man? When mac users/programmers say "Our platform is great!", windows users/programmers don't say "Ours is too!", but rather insist on "No, you suck!". Its always the same story. Just thought I'd point it out. Here is what I say: "Get a friggin' life! If your OS is so great, then there is no reason to say how every one else sucks because they think theirs is too." Or do you have some deeper issues with your OS that we don't know about and this is the source of your hostility? Perhaps if you talk it through you will be happier. Or maybe you could switch to a good OS. Just a suggestion. No need to get defensive about it.

  • Re:Long Answer? (Score:3, Insightful)

    by dcam ( 615646 ) <david.uberconcept@com> on Tuesday May 06, 2008 @12:17AM (#23308372) Homepage
    Yeah, I think that Vista really demonstrates the Microsoft of today. They have a number of problems:
    1. They aren't attracting the kind of people they once were, and many of the very good people have left. This exacerbates their other problems.
    2. They are still trying to develop the same way they used to (cowboy), but are now finding that it does not scale well for the size of projects.
    3. There seems to be a lack of long term direction, planning and vision. And by long term I mean as short as 3 years from now. This might be a result of 1.
  • by Vectronic ( 1221470 ) on Tuesday May 06, 2008 @12:22AM (#23308400)
    People who haven't given Visual Studio much of a chance often think Visual Studio is a piece of crap.
  • Re:Long Answer? (Score:5, Insightful)

    by KutuluWare ( 791333 ) <kutulu.kutulu@org> on Tuesday May 06, 2008 @12:53AM (#23308566) Homepage
    You must have had access to the sooper sekrit article with all the illustrations in it. The Ars article I read a blatent Mac fanboy bragging about Cocoa, with an extra two tacked-on pages of hyperbole and baseless accusations about how much .NET sucks, backed up with exactly 1 concrete example: that you have to know which Windows Forms operations are thread-safe (hint: none of them). He even finishes that thought by pointing out that most other GUI frameworks have exactly the same problem. I can probably rattle two dozen cases from memory in the old Win32 API where MS made obviously retarded design choices, but he can't even come up with a single actual .NET class method that he doesn't like when he's writing an article about it?

    I am in that third group of developers this article was supposedly written for. I absolutely abhor poorly written code, cheap workarounds, etc. And I make a living off .NET and I love it. I usually find that the Framework already does anything I'd expect a base class library to do and a bunch more. The code I write against it is way more elegant than what I typically see from, say, your random GTK app. Is that because .NET is inherently better than gtk, glib, glibc, etc? No, I don't sit around whining about how Microsoft "blew it with developers" because they didn't write all my code for me... I spend my time writing good code.
  • by SuperKendall ( 25149 ) on Tuesday May 06, 2008 @01:56AM (#23308894)
    I too have "been there, done that" on a lot of platforms.

    The term you are looking for is "enabler" - Microsoft is an Enabler for other applications to engage in bad practices, for users to engage in bad security.

    As you say it makes a lot of people happy now, but look what else it has given us - lots of decrepit systems, and hundreds of thousands of zombies that make our lives miserable in other ways.

    Sometimes even a business can't just be about making people happy, it has to be about moving the market as a whole to dry land when they see the flood coming.

    Just like the Spiderman quote tells us.

  • Re:Long Answer? (Score:3, Insightful)

    by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Tuesday May 06, 2008 @02:11AM (#23308964) Journal

    I agree. It sounds to me like this guy used .NET for a year or so around 2002 when it was brand new and then left and hasn't looked again for the last six (6) years.
    Well, certainly, one argument he makes seems to be both dated and out of touch:

    the last group could use C++ or whatever beret-wearing funky scripting language was à la mode at the time. This all worked out fine, because one of the few nice things about Win32 is that it was designed for C. C is in many ways a very simple language, and it's also a ubiquitous language. As a consequence of this, pretty much every other programming language created in the last couple of decades can, one way or another, call C APIs.... .NET isn't like that. Although .NET can call C APIs (just like everything else can), the real objective is for all programming to reside in the .NET world. .NET is meant to be the entire platform, with all the different languages that people use living inside the .NET environment.... It's still possible to use different languages with .NET (in fact, it's easier than it was in the pre-.NET days). Just now, the different languages all use the common set of .NET APIs for drawing windows on screen, or saving files, or querying databases, and so on.
    Here's my take, as someone who pretty much hates MS, and would rather avoid .NET if possible... .NET is trying to be the new C.

    All his support for C could apply to .NET, and all his criticisms of .NET as a platform for people to run whatever they want could easily have applied to C. The one difference is that C simply has more adoption now.

    Certainly, because it's so trivial to call out to C from .NET, there's nothing to stop you from creating and distributing your own .NET library, just as people distribute C libraries now. If your library needs to talk to the system in a way you can't from within .NET, you call out to C -- just as, in a C program, if you need to do something you can't in C, you use ASM.

    This frustration is exacerbated when it's compared to .NET's big competitor, Java. Java is no panacea; it too is aiming roughly at the middle kind of developer, which is understandable, as they're the most numerous. But Java's much more high-minded. It's much stronger on concepts, making it easier to learn.
    .NET can call to C absurdly more easily than Java can. And C# supports things like closures -- at least, that's what they look like -- I know of nothing similar for Java.

    I can't speak to the criticisms of the actual API itself. But that would seem to be more a criticism of .NET as implemented on Windows -- as the successor to Win32 -- rather than a criticism of .NET vs Java, or of .NET vs win32.

    Although, glancing over at some of these, like the passing of two ints for the size of a file -- even on 32-bit Windows, that's kind of stupid. 64-bit integers may not have been fast, but they were certainly possible.
  • by pimpimpim ( 811140 ) on Tuesday May 06, 2008 @02:53AM (#23309124)
    What's the use of legacy support anyway. If you have a windows 95 application, it will always have problems running under XP. If it needs to use special PC ports (e.g. access to serial connections) it will be hell to get it working.

    I understand the need at some places to keep running the old software, I've seen spectrophotometers that had to be connected to an OS/2 program, just because the software was only written for OS/2, but those cases you should either use virtualization, or treasure your old hardware.

  • Re:Long Answer? (Score:3, Insightful)

    by nguy ( 1207026 ) on Tuesday May 06, 2008 @03:33AM (#23309334)
    it's been well documented that MS went back on their word to build a .Net based OS that started fresh.

    And this is different from OS X... how? Apple has no intention of abandoning Carbon, its old, hairy Win32 equivalent. And Cocoa itself is just a slightly cleaned up NeXTStep. So, it's not like Apple has these magical, shiny, new APIs either.
  • Re:Long Answer? (Score:3, Insightful)

    by nguy ( 1207026 ) on Tuesday May 06, 2008 @03:36AM (#23309348)
    If you can't even read his argument without getting mixed up, then your future is in trouble. (OTOH you have a bright future as a Slashdot poster. Not reading TFA is henceforth passé; reading it and getting it entirely wrong is the new standard.)

    No, he is saying that the argument is confused because it mixes up Win32 and .NET. That's a problem with TFA.

    If you want to compare Windows and OS X as modern platforms, you need to compare the modern APIs, that is, .NET against Cocoa, nothing else.
  • by Anonymous Coward on Tuesday May 06, 2008 @03:41AM (#23309370)
    >> How this is different from a simple function in C is beyond me

    It's no different. But do you really need it to be different or you are just a blind OOP fanatic ?

    Describe the sin function. Why the hell should it need an instanced class ? Takes a number, spit a number everytime with the same logic. No different than the - operator.

    I find the static class choice makes much more sense than instanced objects. OOP is a tool and a solution.. not THE solution everytime.
  • Re:Long Answer? (Score:3, Insightful)

    by hatchet ( 528688 ) on Tuesday May 06, 2008 @04:34AM (#23309610) Homepage
    I don't think Microsoft wanted to be backward compatible, people - users wanted backwards compatibility.

    It was same thing with processor architectures amd (x64) vs intel (IA-64). Intel's IA-64 (Iteron) is FAR superior architecture (256 GPR, register rename, register splitting, multiplexed operations, etc...) with no 8, 16 and 32-bit register functions for backwards compatibility. (Usage of emulator or additional 32bit core can be used to overcome this)

    While x64 was just extension over IA-32 and current processors (Intel or amd x64) still have 8 and 16bit support functions (add ax, bx).

    It happened because of you - users, who wanted to run your current (old) applications on new platform. Everyone loses, because we're using inferior architecture that supports 30year old applications. (yes, x64 is backwards compatible with 8088 processor which is asinine)
  • Re:Long Answer? (Score:5, Insightful)

    by DrPizza ( 558687 ) on Tuesday May 06, 2008 @06:35AM (#23310072) Homepage

    No, he is saying that the argument is confused because it mixes up Win32 and .NET. That's a problem with TFA.
    But the article doesn't do that, except when describing how details of Win32 leak into .NET.

    If you want to compare Windows and OS X as modern platforms, you need to compare the modern APIs, that is, .NET against Cocoa, nothing else.
    But you can't. MS has added new features to Win32 (and VC++/MFC), and MS is going to continue to do so in Windows Seven. For example, Vista has a new transacted (database-style ACID transactions, not just journalled) filesystem. .NET doesn't support it; you've got to use Win32 to use it. Even though .NET does have transaction support (for COM+ transactions and database transactions) it doesn't support TxNTFS. So you've gotta use Win32. Or how about an MS-supported ribbon control? You've got to use MFC, and in Windows Seven there should be a native code ribbon control as part of the OS proper. In both cases, no managed code.

    Having to drop into Win32 to call some legacy thing that no-one should really be doing but which you have to do for backwards compatibility, that I could sort of understand. But having to drop into Win32 to call new features that have only just been added? Anyone saying "stop using Win32, just use .NET" doesn't know what they're talking about.

  • by jabjoe ( 1042100 ) on Tuesday May 06, 2008 @06:38AM (#23310084)

    but it's part of the way programs used to be written.
    What's this use to be written?
    We had a script kiddy here who made a horrid tangled mess, hard pathing everything, including to a directory called "Not_Used_Anymore". He didn't know better.
    The horrors of hard pathing are alive and well.
    Hard pathing is just coding in a path into your source like any other constant. Sometimes it makes sense to do it (small personal batch script for instance) and some will always do it where they shouldn't (in something compiled or large).
  • I don't see it (Score:4, Insightful)

    by golodh ( 893453 ) on Tuesday May 06, 2008 @07:30AM (#23310298)
    Where exactly did Microsoft "drop the ball" with developers?

    According to the article there are three types of developers: (I) the ones who bang Excel macros and Access databases together with VB (not very many), (II) in-house developers for large companies who program in whatever language is in demand (the vast majority), and (III) craftsmen-programmers who look for clean orthogonal programming tools and also program in their spare time (a few).

    The article goes on to argue that Microsoft catered very well for categories (I) and (II), and not at all for category (III.)

    Since I believe that the programmers who make stand-alone third-party applications mostly belong to category (II) I absolutely don't see how or why Microsoft supposedly "dropped the ball" for any developers except category (III). The article points to the messy API's of Win32 and the shadows that projects unto the .NET framework. Ok, fair enough, but who cares?

    Not the end-users and not the managers. And they're the ones who determine where the money, and hence the bulk of the development effort goes. That means that what end-users actually see and care about, their _applications_ will continue to be in plentiful supply for MS-Windows.

    Sorry, but the author will have to do a lot better to convince me that Microsoft shot itself in the foot as regards development effort. It's not the smartest thing that Microsoft could have done to alienate the craftsmen-programmers but I don't see how that puts a dent in their business.

  • Re:Long Answer? (Score:1, Insightful)

    by Evil Kerek ( 1196573 ) on Tuesday May 06, 2008 @07:38AM (#23310328)
    I've been programming for over 20 years and yes, it's mostly MS bashing.

    First off, you're obviously an MS basher (MS languages vs good languages? oh you mean C++?) Not sure what word you think MS went back on. .NET is pretty cool. The IDE still needs some work, but it's one of the better ones I've worked in. C# is quite cool.

    Past that..did you actually just suggest that MS scrap backward compatibility? Are you serious? Yes, the linux zealots would love that - they might actually have a chance at a desktop...because of the user revolt. I mean, you are suggesting that a company PISS OFF a good portion of it's base users. ROFL - so that's what linux needs to be on a level playing field? Weak, man, weak. That's a new approach...let's see...eliminate your base so we have a fair chance at the desktop. Please. Obviously you don't run a business.

    One of the main reasons Windows is the way it is, is BECAUSE of the backward compatilibity requirement. If Linux actually HAD some desktop penetration, it too would have to cater to the businesses and people running 15 year old software that they can't seem to get rid of. But, alas, that's not much of a problem, is it?

    Personally, I use whatever works - and it's alot easier to make money in the windows world. Say what you want, but if I'm going to write desktop software, I'll pick the desktop with the most users.

    Your reply should be modded 'pandering'.

    EK
  • Re:Long Answer? (Score:3, Insightful)

    by BasharTeg ( 71923 ) on Tuesday May 06, 2008 @08:05AM (#23310480) Homepage
    No, he doesn't. Read about how he claims that the form thread synchronization mechanism is broken in .NET and will sometimes lie to you about what thread you're in which will cause your application to crash. This of course is news to us .NET developers who use the form thread synchronization in all of our multi-threaded applications and don't experience the FCL "lying" to us and we don't experience crashes because of false impressions that we're in the form thread. This is the kind of bug report I'd expect from a first year computer science student learning how to do form thread synchronization for the first time. His statements are complete horseshit, and it shows that this retard can't even accomplish the most basic tasks in .NET. Therefore, I ask who the hell is he to write a review of .NET versus Cocoa?

    I think we could easily make that a litmus test for writing an article comparing the .NET platform to any of the other great platforms out there like Java and Cocoa:

    If you can't figure out how to do basic form thread synchronization to allow worker threads to safely update your form's controls without claiming there's a flaw in the foundation class library, you are not qualified to write an article about .NET programming.

    I won't even start on his biased slamming of enterprise systems development. It's clear that his knowledge of software engineering is limited to applications and he should just keep all other software engineering topics out of his mouth.

    I'm sure Cocoa is an awesome enough development platform without needing this dumb ass to promote it through FUD and lies. I'd like to see him actually back up his claimed flaws in .NET with real code samples demonstrating them so we can point out his obvious errors and what a tool he is.
  • Re:Long Answer? (Score:5, Insightful)

    by DrPizza ( 558687 ) on Tuesday May 06, 2008 @08:35AM (#23310710) Homepage

    The article didn't actually describe any accurate parts of Win32 that leak into .NET, except that WinForms is based on the WinProc event model of GUI development. That's one of the many valid ways to implement GUIs, and there's no reasoning as to why this isn't a valid design decision for Microsoft to make.

    Well, there is a good reason why it's not valid: because it makes .NET developers give a damn about HWNDs, message pumps, and the interactions between the two.

    Other than that, he points out a bunch of flaws in Win32 and implies that they "leak into .NET" but he fails to actually demonstrate any of them.

    Off the top of my head we have, for example:

    • the entire crypto lib (including e.g. certificate handling as well as core crypto functions)
    • SSL handling equally has Windows-specific portions
    • SocketException (especially ErrorCode)
    • Socket.UseOverlappedIO
    • Socket.IOControl
    • System.ServiceProcess.* (this stuff should be in Microsoft.whatever, not System!)
    • System.Management.* (ditto)
    • System.Data.SqlClient.*, System.Data.OracleClient.* ((a) the core interfaces should be better (b) the vendor-specific providers should not be in System)
    • The "Handle" properties found in e.g. Socket, FileStream, and the aforementioned System.Windows.Forms
    • Large tracts of System.EnterpriseServices

    Win32isms are abundant.

    Further, your arguments that somehow cutting edge enhancements like Vista's new TxNTFS should magically appear in .NET by now make no sense to me.

    Let's just recap the argument, shall we?

    1) Claim: Win32 is clunky and horrible

    2) Response: Write in .NET

    3) Claim: .NET can't do everything Win32 can do, forcing me to use Win32

    4) Response: "your arguments [...] make no sense to me"

    Look, if the argument is going to be "Don't use Win32, use .NET" then .NET has to do all the things that Win32 can do. So which is it?

    Either I should be using .NET--in which case MS's failure to add new Win32 features to .NET is a problem--or I should be using Win32--in which case "use .NET" is not a suitable response to cited flaws with Win32. You can't have it both ways, so which is it to be?

  • Incredible... (Score:3, Insightful)

    by thesteef ( 1279258 ) on Tuesday May 06, 2008 @08:43AM (#23310750)
    I really should leave this one alone, but I just can't. This article is so unbelievably biased, it is truly amazing that a site like ars allows a series like these to exist. The person who's written this series has obviously no real programming knowledge on any platform.
    Moreover the way he drops in his little falsehoods borders on intent. Each and every paragraph contains one or more blatant falsehoods. Going through all of them would take way to much time.

    Apparantly this Peter Bright's tried to build some winforms stuff (and failed) and he's tried to open a file (and failed somehow). These are his two major arguments against the platform.

    Let's try to introduce some facts. First of all the winforms library is indeed not multithreaded. This goes for most windowing libraries. Swing is an example that springs to mind but there are many more. Making it totally thread safe would introduce a lot of overhead, making everything much slower than it needs to be. If you need to use additional threads, there are well documented ways to do this. Maybe Pater should try it... Second of all the winforms library is a very very small part of the total api. Just saying there's lot of little other things, without going into any detail is a cheap way of making a bad point. No API is perfect but I would say given the alternatives out there it's easily one of the cleanest and well thought out api's I've used in the last 6 years. Furthermore, it the author could get his head out of his nether regions he might look in to WPF, WCF, C# 3.0 etc etc. All technologies that put .NET lightyears ahead of the competition right now. Writing these little misinformed articles is not going to change that.

    This person comes across as a total beginner. You know the type, probably programmed some stuff in c++ and now thinks he's a guru on everything. In reality he's an armchair programmer, writing knee yerk articles because he coulnd't get his file to open. A lot of programmers (myself included) go through a phase like this, most move on and start seeing the bigger picture. I guess some don't and just write articles about it.

    I know the average slashdotter probably won't care about an anti-microsoft hit-piece but if you're confident about using linux or mac-osx (both of which I think are perfect alternatives btw) ask yourself, why would you need lies and falsehood's to attack the 'competition'.
  • I live here. (Score:3, Insightful)

    by kcdoodle ( 754976 ) on Tuesday May 06, 2008 @09:51AM (#23311394)
    Hurrah!

    Make it buggy and as difficult as possible. That just gives me more work. I can always find a way to make my code work. Even if I have to write some assembly, or a port redirector. Call me a hacker - I don't care, that's a badge of honor.

    If it were easy, anybody could do it. Keep it up Microsoft! You will keep me working and making a good wage for years to come. I like doing crossword puzzles too, and making things work on various Windows/Browsers/whatevers is just another puzzle people actually pay me to solve. It is all very cool. Just depends how you look at it.
  • Re:Long Answer? (Score:3, Insightful)

    by VoidEngineer ( 633446 ) on Tuesday May 06, 2008 @11:12AM (#23312364)
    I'm curious as to why you're using any Win32 calls at all. I've been developing in C# for about three years now, and I can't ever remember making a single Win32 call. And I've been developing some fairly robust applications... i.e. multithreaded, networked, double buffered graphics, disk io access, numerical optmization algorithms, etc. The closest I ever came was when I was trying to figure out the size of the desktop, but eventually I figured out how to do that inside of .Net also. Everything else has been somewhere inside of .Net. Granted, sometimes it's been difficult to track down where in the API to find a particular function; sometimes I've had to write some wrappers and funky helper methods; but, I've never had to resort to a Win32 call. At the same time, I've *decided* not to make any Win32 calls, for portability purposes (as I want my apps to eventually be Microsoft free and be able to run on Mono). So, whenever I run across a place where I *could* use a Win32 call, I sigh, and then start looking for another way to achieve the same task within the .Net framework. Takes longer, requires more research, but keeps the application all within my own namespace and maintains portability and independence from a single vendor. I mean this is just my two cents, but it sounds to me like you haven't made a design decision to NOT use Win32 calls; and thereby, when you run into a situation where you *could* make one, it's a valid option, and you use it. (On the other hand, you design goals could be more in keeping with systems programming than applications programing; in which case, I would say... well, what did you expect?)

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...