Slashdot Mirror

Rewrite: "Over time, Microsoft Windows XP tends to mysteriously ... decrease stability and performance (in every way imaginable".

I've experienced that, many times. Windows is unstable. The instability helps Microsoft sell new versions of its operating system.

Summary of the Slashdot article about Windows XP SP3 crashes:

Microsoft has known about one of the underlying problems for a long time. See KB888372. It would have been easy to prevent the crashes merely by having SP3 installation do the work mentioned in the KB888372 article. However, apparently because of work avoidance, or an attempt to discourage people from using Windows XP, Microsoft did not do the necessary work.

I got hit by this bug when the patch went live last week on Windowsupdate. As the article states, the solution in was to disable intelppm.sys from safemode. It's a lot quicker if you do it using autoruns. It's too bad this article wasn't posted last week. It would have saved me a lot of trouble shooting time.

Just how many "alternative architectures" does XP run on? Last I checked, none. I think Microsoft's multi-architecture support for their main operating systems died after NT4 (along with support for DEC's Alpha) and they went x86. Looking at Microsoft's support page, they say Pentium or compatible processor, so that means x86 only.

See CreateRemoteThread on how that rootkit managed to hook itself into the explorer.exe process.

You could have used something really simple like Process Explorer (Sysinternals) to put the evil thread inside the explorer.exe process to sleep (note that this doesn't remove/destroy the thread, it just puts it to sleep so that it is 'frozen in time'). This has the advantage of allowing you to continue the cleanup without having to worry about another process trying to rehook explorer.exe with a bad thread (unless you want to monitor API calls to find out what other process/thread was trying to protect the thread in explorer.exe). Most rootkits are designed to check if their processes/threads are intact and if not, the rootkit will spawn itself again. A sleeping process/thread is often considered by rootkits to be in a perfectly working condition, thus preventing a respawn.

But you can't. The Guardian Angel has a posse.

Given C#Âand the Common Language Infrastructure are ECMA and ISO standards I don't think you can credulously call them "proprietary formats".

It would be fair to point out that Silverlight itself is not a standard in the same vein, but the GPL'd implementation of Moonlight (part of Mono) is being developed with active collaboration from Microsoft

To quote:

Microsoft, on behalf of itself and its Subsidiaries, hereby covenants not to sue Downstream Recipients of Novell and its Subsidiaries for infringement under Necessary Claims of Microsoft on account of such Downstream Recipientsâ(TM) use of Moonlight Implementations to the extent originally provided by Novell during the Term

They go on to note they may choose not to extend such license on future implementations, but that if they chose not to re-extent that agreement they confirm it would not retroactively apply to any software using a previously released version of Moonlight Plug-In.

It is perhaps of note that they not granting immunity to libraries which implement proprietary Microsoft functions which are not part of the standard - which also impacts C# developers using Mono.

Now all that may not sit comfortably with you - I can't say I like it either - but in fairness it's better than the situation with Flash, and the situation as-was with Java, but never the less I still really like C# and the CLR (thank you Mono, and dotGNU) and that's true regardless of what Microsoft are up to.

Microsoft could choose to do all sorts of weird proprietary stuff with future versions, as Sun could with Java, or Apple with Objective-C, but I'm not worried about them either, for the same reason. Namely that if a vendor goes down that route, I wouldn't follow them down it - because it's standardized and their is an open source implementation released under the GPL, I'm not under any obligation to. If they started doing things they didn't like, I'd continue using an existing open source version, free of vendor interference.

Parent contains misinformation. Silverlight does not "exist only for Windows". See here (Microsoft supports Windows and OSX) and here (Linux).

Try looking at the Silverlight-powered Microsoft Download Centre someday.

Oh, wait, you're bashing Microsoft. Let's not allow facts to get in the way of that.

> odd that did not really start some sort of significant promotion for their technology (unless I missed it)

They certainly are promoting it. Even using Firefox 2.0 (on Win XP), http://www.microsoft.com/en/us/default.aspx opens with a box "layered" on top of the main page:

Enhance your experience on Microsoft.com with Microsoft Silverlight
Microsoft Silverlight delivers a new generation of high-quality audio and video, engaging media experiences, and interactive applications for the Web.
Approximately a 1MB download and a 20-second install.
[Click to install]
By clicking "Click to install" you accept the Silverlight License Agreement.

And there is even a tiny [No Thanks] button.
Of course that was what I picked :-)

The problem is not that Microsoft is trying to introduce a new technology. The problem is that Microsoft is extremely adversarial toward customers, sometimes, in my opinion. For example, Microsoft will soon begin FORCING people to install Silverlight if they want to download files from microsoft.com/downloads/.

At least the first 2 versions of Microsoft products usually have very severe bugs. For example, Windows XP and Windows XP SP1, and Windows Vista and Windows Vista SP1 were or are full of grief for administrators.

Customers don't want to be beta testers for Microsoft, any longer.

After Microsoft has forced a significant number of its less knowledgeable users to install Silverlight, Microsoft salesmen will begin talking about "significant market share", if the past is any guide.

"I think Flash has just gone too far down the wrong route, as application development in it seems like a hack." My experience with Macromedia is that it was always a sloppy company. Unforunately, Adobe management seems to be malfunctioning recently.

I just checked Microsoft's site again, and this was the worst page of the few that I visited:

http://www.microsoft.com/smallbusiness/resources/technology/hardware/do-you-need-to-turn-off-your-pc-at-night.aspx

First of all, there's a "loading" Javascript message in the middle that never goes away(correction: it went away after 3 minutes of letting the page load. On a second try, it never went away. It must be calling some resource that is overloaded or something)

While the page is "loading", you can see the text you are interested in the background, but you can't read it because it is jumping around 3 columns, from left to center to right. That's right, the text keeps jumping all the time.

When the page finally settles (after a few minutes), there is a page footer that does not like to go at the end of the page - instead it decides to settle smack dab in the middle of the page, thus interrupting your reading of the text.

Really, the page is so bad, I'm astounded that it comes from the world's "leading software technology developer" *roll eyes*

It works fine for me.

Read the white paper about SP3.
http://download.microsoft.com/download/6/8/7/687484ed-8174-496d-8db9-f02b40c12982/Overview%20of%20Windows%20XP%20Service%20Pack%203.pdf

From what I can tell, the problem is that it's conflicting with networking drivers, which are a kludge in a lot of cases. Of the changes, five of the eight are networking and permissions based, and my guess is that the machines with problems are either:

A:Not running the latest .Net framework.
B:They are using some half-baked onboard networking adapter that the company in question needs to upgrade the drivers on. That a lot of the complaints seem to be coming from laptops points to a likely problem with non-compliant hardware and drivers.

Doubly so since a clean install seems to fix it for many people. I'd recommend if your machine is having a problem, try turning the built-in networking off in the BIOS.

I have a modern PCIe ASUS motherboard and everything works perfectly. I made sure that before I applied the patch that I was up to date with every previous patch and had upgraded windows media, Java, direct X, my drivers, and .net to the latest stable versions. The install took a few minutes since everything in the patch was pretty much already installed and working beforehand.

Oh - I run XP Pro. This version seems to have less issues from what I can tell, which isn't surprising, really.

Well, it sounds like the concept of shelving; a kind of partial commit that only you can see, and if you like, can later make public. I don't believe you need distributed SC for that; there's nothing inherient that requires a local server running. I believe MS' Team Foundation Server already supports this. http://msdn.microsoft.com/en-us/library/ms181283(VS.80).aspx

Maybe it's not the same thing though. To me, the key difference would be running your own private SC server locally to handle the feature vs. not having any local server but the central server knows to "hide" it. At least that's how I would think a distributed source control system would work.

It isn't even near free.

from MS.com
Visual Studio Team System 2008 Development Edition
with MSDN Premium Subscription $5,469 $2,299

Don't forget that's $5k for the fist year, and then $2k per year renewal. It would be cheaper just to buy it, but then you'd not get the dev licences for the OS and other tools. shame really, MS used to be really good with these things but they've become too big, difficult to install, difficult to use and really expensive.

Prove it!

98 was always meant for home use, and 2000 was always meant of work/business use.

There was certainly no trying to get everyone to install what was absolutely a work OS at home.

Hell, there were hardly even any PCs at the consumer level that even came with 2000!

This is just a wrong argument.

I can site links, can you??
http://www.activewin.com/win2000/index.shtml
http://en.wikipedia.org/wiki/Windows_2000
http://en.wikipedia.org/wiki/History_of_Microsoft_Windows
http://www.winsupersite.com/faq/2000_old.asp
http://www.microsoft.com/windows/WinHistoryDesktop.mspx

Not one of them mentions it was for home use, in fact, quite the opposite.

Vista has this feature, there's a tab called "Previous Versions" in the properties dialog for files and folders. Microsoft calls this feature Shadow Copy on the list of Vista features.

Except that it's only available on the Ultimate and Business editions (footnote D as of the time I linked it). Home users don't get it.

But it's a great feature (despite the crappy slow and flaky UI), and one that should be available on all versions of Vista if Microsoft was intelligent and not trying to nickel-and-dime their customers. It's the only feature of Vista I've ever used that made me think "I'm glad I'm using Vista, I'd have been screwed in XP."

Vista has this feature, there's a tab called "Previous Versions" in the properties dialog for files and folders. Microsoft calls this feature Shadow Copy on the list of Vista features.

Except that it's only available on the Ultimate and Business editions (footnote D as of the time I linked it). Home users don't get it.

But it's a great feature (despite the crappy slow and flaky UI), and one that should be available on all versions of Vista if Microsoft was intelligent and not trying to nickel-and-dime their customers. It's the only feature of Vista I've ever used that made me think "I'm glad I'm using Vista, I'd have been screwed in XP."

Bcastner's Broadband/DSL Reports forum thread shares Jane Maliouta's IEBlog about Microsoft Windows XP SP3 and how it'll work with the various released versions of Internet Explorer (v6.0 to 8.0 beta 1).

Also, this is another why you shouldn't upgrade right away, especially major upgrades. SP3 is not urgent. I am just going to wait until MS or something else forces me to upgrade to it. I am fine with SP2 and MS is still supporting it for a while (no idea when it ends).

Bcastner's Broadband/DSL Reports forum thread shares Jane Maliouta's IEBlog about Microsoft Windows XP SP3 and how it'll work with the various released versions of Internet Explorer (v6.0 to 8.0 beta 1).

Also, this is another why you shouldn't upgrade right away, especially major upgrades. SP3 is not urgent. I am just going to wait until MS or something else forces me to upgrade to it. I am fine with SP2 and MS is still supporting it for a while (no idea when it ends).

Bcastner's Broadband/DSL Reports forum thread shares Jane Maliouta's IEBlog about Microsoft Windows XP SP3 and how it'll work with the various released versions of Internet Explorer (v6.0 to 8.0 beta 1).

Also, this is another why you shouldn't upgrade right away, especially major upgrades. SP3 is not urgent. I am just going to wait until MS or something else forces me to upgrade to it. I am fine with SP2 and MS is still supporting it for a while (no idea when it ends).

It was through automatic update... and this same error is happening to a ton of people online; google for: xp "service pack 3" access denied. Microsoft already has a few knowledgebase entries about it. That was what I was talking about in my original post....... yeeeeesh....

See also Polyphonic C#.

Let me give you a real-life example involving Microsoft, even if it's one that I've used a few times before. The company I work for built depends heavily on a FoxPro program with a 15 year history. Although it wouldn't have been my first choice, it's served us well over the years.

But now it's dead. There will never be a version based on .NET. There will never be a FoxPro 10. It may or may not run well on Vista (although they have a community-supported side project called "Sedna" that hopes to cobble something together). Now we're scrambling to port our mission-critical application - the one that keeps revenue flowing - to something more future-proof. The current version still runs great, but there's no assurance whatsoever that we'll be able to use it a couple of years from now. VB6 legacy apps are in the same boat, but we're lucky enough to only have to deal with one deprecated technology at a time.

So, yeah, my warning wasn't hypothetical. Redmond giveth and Redmond taketh away, and there's a very real risk that the components of your livelihood will simply disappear. Ours did. Fortunately, we (and from the sounds of it, you) are nimble enough to shift directions and move on with something new. We'll pull through this unscathed. That doesn't mean the transition will be pleasant, though, and there's a lot of other stuff we'd rather be spending our development dollars on.

MSKB 323302: PRB: Inert Virus Found in Korean Language Version of Visual Studio .NET

However, you can bring back those thrilling days of yesteryear with this screen saver.

• Microsoft Expands Document Interoperability
  • "Expanding on its customer-focused commitment to interoperability, Microsoft Corp. today announced the creation of the Open XML Translator project. The project, developed with partners, will create tools to build a technical bridge between the Microsoft® Office Open XML Formats and the OpenDocument Format (ODF)."

• Microsoft (Funding, Architectural & Technical Guidance and Project co-coordination)

Microsoft Word Viewer - it's free.

No, no, no. You have it all wrong. In Unix, everything's a file. In open source, everything's a beta! It seems to be creeping into some proprietary software as well. Actually, I have this theory that the entire universe is just a beta project; it would explain a whole lot about these people around me...

Because MSDN only wishes they could touch Qt in ease of programming.

C++ compared to Java (and I have to assume it's close cousin C#) is hands down the better choice

with Qt you get the cross platform, garbage collection (not 100% but I have less memory leaks with my Qt programs than with my Java programs) and so much more.

Let's see do a decent GUI or even server using MSDN which will go cross platform!

Speaking of licensing fees, just how many developers do you have? Is it safe to assume that MS sells one copy of MSDN and lets all of the developers in your company use it? I doubt that!

Also, boxed standard edition of Visual Studio would cost one $299, and it comes with MSDN as well (that one is for single developer only, though). Still quite a bit cheaper than Qt ;)

Anyway, this isn't to say that Qt is not a great product. The price label is also quite warranted - you want good stuff, you have to pay for it. And it's not really Trolltech vs Microsoft, at any rate - commercial versions of Qt have that nice Visual Studio integration feature, after all...

Of course, even better (and a recommended approach in .NET 2.0) is to just use BackgroundWorker.

His big complaint about Windows Forms was threading, which doesn't seem like a big issue (you may have multiple threads once-in-a-while, but will you have more than one working with the UI?)

It's also ironic how he then goes on to rant about Win64, conveniently forgetting to mention that any pure .NET application is, in fact, fully 64-bit enabled on any x64 or IA64 Windows platform without even a need to recompile.

There are weird versions of a lot of things left over for the VB6-VB.Net porting wizard to use.

The selection of functions on the String class has some very strange ommissions (.Right(n) would be nice).

The IO libraries need a smooth system to switch between strings and structured objects when dealing with paths and filenames.

FTP is still way too difficult.

WebRequest request = WebRequest.Create("ftp://...");
Stream data = request.GetResponseStream();
...

ICollections implement an IEnumerator interface and have an Enumerator object which counts the objects in a collection. Think of an enumerator as an odometer (like the one in your car). If the object implements ICollection, then it has an odometer, which you can get the count from. Arrays just have size.

Count is not a method; it is not asking "Count how many things are in this object". It is a property, and as such an intrinsic feature of the object (that behind the scenes it might have to do the verb thing is beside the point--it's semantically a property, even if it's actually a verb). And even if one were a verb--why should be it?

Again, difference between an attribute and a verb. LongLength is an attribute of an object, such as height or width. Whereas Count is like an odometer in your car. Your question is kind of like asking why can you travel tens of thousands of miles along the US highway, but my odometer in my car only goes up to 1000. Well, that's just the way the odometer was made. Length of trip is distance, whereas your odometer is a counter and is only a *measure* of distance. It's simply a distinction the language makes.

Again, though, the language doesn't make the distinction you are making. Count is a property, just like Length. If Count were a method I could sort of understand the difference (I don't really agree with it, it seems spurious, but I could sort of understand it). But it's not; it's a property.

Chunking. .NET gets used on both 32 and 64 bit platforms, and the performance penalty for splitting a 64 bit word into two is greater than using two 32 bit words. In the first case, you still have to use 64 bit words, but you pad the first 32 bits with zeros, and convert to 32 bit words. Requires an extra pass through the processor to calculate, whereas adding two 32 bit words into a 64 bit word is trivial. I'm not explaining this concept well, but if you look it up you'll find more info on the question you're asking. The design decision was based on current market saturation of 32 bit processors, and the LongLength was an added conversion for the 64bit programmers.

But LongLength means we won't have a clean transition, because it means people will have to fix up APIs to take longs where they currently take ints; making everyone pay the price for longs might be a short-term cost (though not a great one), but it'll be a long-term gain.

Using the odometer analogy as above, the enumerator only goes forward; although you *can* reset it. If you want to do reverse iteration, copy your collection into a new collections backwards, and iterate over that new object. Alternatively, for most reverse or bidirectional iterations, you'll simply want to ditch the 'foreach' loops, and use a simple 'for' loop. Then you can start high and use decrement iterators to count down. I also like to use decrementor collections which get an object removed with each pass of the for loop.

That really doesn't answer the question. In both Java and C++ I have iterating objects (java.util.ListIterator, C++ bidi/random iterators) that can go forwards and backwards. I use these quite regularly; why can .NET not provide the same?

You need to get the IEnumerator object from the ICollection, using the GetEnumerator method. It will have a Position field.

Neither here: http://msdn.microsoft.com/en-us/library/system.collections.ienumerator.aspx Nor here: http://msdn.microsoft.com/en-us/library/78dfe2yb.aspx So I'm not altogether sure what you mean.

Probably implemented somewhere else.

I don't understand what you mean.

You're splitting hairs here. It's a strongly typed language. It's meant to be explicit, not inferential. In other projects, besides yours, do

ICollections implement an IEnumerator interface and have an Enumerator object which counts the objects in a collection. Think of an enumerator as an odometer (like the one in your car). If the object implements ICollection, then it has an odometer, which you can get the count from. Arrays just have size.

Count is not a method; it is not asking "Count how many things are in this object". It is a property, and as such an intrinsic feature of the object (that behind the scenes it might have to do the verb thing is beside the point--it's semantically a property, even if it's actually a verb). And even if one were a verb--why should be it?

Again, difference between an attribute and a verb. LongLength is an attribute of an object, such as height or width. Whereas Count is like an odometer in your car. Your question is kind of like asking why can you travel tens of thousands of miles along the US highway, but my odometer in my car only goes up to 1000. Well, that's just the way the odometer was made. Length of trip is distance, whereas your odometer is a counter and is only a *measure* of distance. It's simply a distinction the language makes.

Again, though, the language doesn't make the distinction you are making. Count is a property, just like Length. If Count were a method I could sort of understand the difference (I don't really agree with it, it seems spurious, but I could sort of understand it). But it's not; it's a property.

Chunking. .NET gets used on both 32 and 64 bit platforms, and the performance penalty for splitting a 64 bit word into two is greater than using two 32 bit words. In the first case, you still have to use 64 bit words, but you pad the first 32 bits with zeros, and convert to 32 bit words. Requires an extra pass through the processor to calculate, whereas adding two 32 bit words into a 64 bit word is trivial. I'm not explaining this concept well, but if you look it up you'll find more info on the question you're asking. The design decision was based on current market saturation of 32 bit processors, and the LongLength was an added conversion for the 64bit programmers.

But LongLength means we won't have a clean transition, because it means people will have to fix up APIs to take longs where they currently take ints; making everyone pay the price for longs might be a short-term cost (though not a great one), but it'll be a long-term gain.

Using the odometer analogy as above, the enumerator only goes forward; although you *can* reset it. If you want to do reverse iteration, copy your collection into a new collections backwards, and iterate over that new object. Alternatively, for most reverse or bidirectional iterations, you'll simply want to ditch the 'foreach' loops, and use a simple 'for' loop. Then you can start high and use decrement iterators to count down. I also like to use decrementor collections which get an object removed with each pass of the for loop.

That really doesn't answer the question. In both Java and C++ I have iterating objects (java.util.ListIterator, C++ bidi/random iterators) that can go forwards and backwards. I use these quite regularly; why can .NET not provide the same?

You need to get the IEnumerator object from the ICollection, using the GetEnumerator method. It will have a Position field.

Neither here: http://msdn.microsoft.com/en-us/library/system.collections.ienumerator.aspx Nor here: http://msdn.microsoft.com/en-us/library/78dfe2yb.aspx So I'm not altogether sure what you mean.

Probably implemented somewhere else.

I don't understand what you mean.

You're splitting hairs here. It's a strongly typed language. It's meant to be explicit, not inferential. In other projects, besides yours, do

Control.InvokeRequired, tells you that some other thread, besides the current thread owns the window. You typically don't care about *which* actual thread it is that actually owns the window, but you do care that it gets the event, which is what Invoke()does for you. And, shocker, it's even in the documentation: http://msdn.microsoft.com/en-us/library/system.windows.forms.control.invokerequired.aspx

Although he sold quite a bit in 1998 to start his foundation...according to this
http://www.microsoft.com/msft/reports/proxy2007.mspx
he is still the largest individual stock holder at 9%.

Smart people use DMA for shuffling around large blocks of data.

Really? So explain to us mortals how you would move a large set of data being processed by the CPU to the GPU via DMA? Do you even know what DMA is?

I can't believe people are this stupid and race to post crap like this to demonstrate their ignorance.

DMA and 32bit/64bit Diagram for you...

32bit All Around - 32bit OS
          / 32bit DRAM \
32bit CPU - 32bit Host Bridge - 32Bit Bus

32bit CPU/64bit Bus - 32bit OS
          / 64bit DRAM \
32bit CPU - 32bit Host Bridge - 32Bit Bus

64bit CPU/64bit Bus - 32bit OS
          / 64bit DRAM \
64bit CPU - 32bit Host Bridge - 64Bit Bus
(note 64bit CPU is restricted to 32bit mode, and 32bit transfer to Host Bridge)

64bit CPU/64bit Bus - 64bit OS
          / 64bit DRAM \
64bit CPU - 64bit Host Bridge - 64Bit Bus

But hey, maybe you know more about OSes and 32bit/64bit than Microsoft:
"Performing direct memory access (DMA)
Adding 64-bit addressing support to a driver can significantly improve overall system performance." from http://www.microsoft.com/whdc/system/platform/64bit/64bitsystems.mspx

And if case you don't realize how DMA and drivers and a 64bit OS relate, here:
"DMA Support
Use the PHYSICAL_ADDRESS typedef to access physical addresses. PHYSICAL_ADDRESS is 64 bits long.
Treat all 64 bits as a valid physical address. Do not ignore the high-end 32 bits.
Use the Windows DMA APIs to ensure correct operation on all platforms. These routines include: Use the new scatter/gather DMA APIs when appropriate.

Significantly improve performance by using devices with 64-bit addressing capability.
" from http://www.microsoft.com/whdc/driver/kernel/64bit_chklist.mspx

The only time 64bit Drivers don't benefit the performance of a system is when the device itself only has 32bits, then the 64bit OS has to double bounce/buffer. But this is not so common anymore, and is a tiny performance hit. Also considering Video cards, and all performance related devices of a modern system are not 32bit limited, it would not apply in the example you are responding to.

Now go somewhere else to troll, and maybe listen to your own advice, this can apply to the idiot that agreed with your post as well:
It is better to remain quiet and have everyone think you a fool than to open your mouth and remove all doubt.

Smart people use DMA for shuffling around large blocks of data.

Really? So explain to us mortals how you would move a large set of data being processed by the CPU to the GPU via DMA? Do you even know what DMA is?

I can't believe people are this stupid and race to post crap like this to demonstrate their ignorance.

DMA and 32bit/64bit Diagram for you...

32bit All Around - 32bit OS
          / 32bit DRAM \
32bit CPU - 32bit Host Bridge - 32Bit Bus

32bit CPU/64bit Bus - 32bit OS
          / 64bit DRAM \
32bit CPU - 32bit Host Bridge - 32Bit Bus

64bit CPU/64bit Bus - 32bit OS
          / 64bit DRAM \
64bit CPU - 32bit Host Bridge - 64Bit Bus
(note 64bit CPU is restricted to 32bit mode, and 32bit transfer to Host Bridge)

64bit CPU/64bit Bus - 64bit OS
          / 64bit DRAM \
64bit CPU - 64bit Host Bridge - 64Bit Bus

But hey, maybe you know more about OSes and 32bit/64bit than Microsoft:
"Performing direct memory access (DMA)
Adding 64-bit addressing support to a driver can significantly improve overall system performance." from http://www.microsoft.com/whdc/system/platform/64bit/64bitsystems.mspx

And if case you don't realize how DMA and drivers and a 64bit OS relate, here:
"DMA Support
Use the PHYSICAL_ADDRESS typedef to access physical addresses. PHYSICAL_ADDRESS is 64 bits long.
Treat all 64 bits as a valid physical address. Do not ignore the high-end 32 bits.
Use the Windows DMA APIs to ensure correct operation on all platforms. These routines include: Use the new scatter/gather DMA APIs when appropriate.

Significantly improve performance by using devices with 64-bit addressing capability.
" from http://www.microsoft.com/whdc/driver/kernel/64bit_chklist.mspx

The only time 64bit Drivers don't benefit the performance of a system is when the device itself only has 32bits, then the 64bit OS has to double bounce/buffer. But this is not so common anymore, and is a tiny performance hit. Also considering Video cards, and all performance related devices of a modern system are not 32bit limited, it would not apply in the example you are responding to.

Now go somewhere else to troll, and maybe listen to your own advice, this can apply to the idiot that agreed with your post as well:
It is better to remain quiet and have everyone think you a fool than to open your mouth and remove all doubt.

Here's a tip. You don't really need an MSDN license to do good Windows development anymore. The .NET SDK provides everything that you need to develop and build great .NET applications and it is free (as in beer).

What's that you say? No VS.NET with the .NET SDK? That's true. Your favorite text editor can do the job with the writing and NAnt can do the job with building it. True, you won't get your precious statement completion that you get in VS.NET unless you use the OSS IDE SharpDevelop.

VS.NET can be more of a crutch than a tool since there is no first class, built in support for modern IoC/DI style MVC frameworks such as Unity or Spring.

Ahm, this is obviously the same kid that wrote the first part, I'd say he probably never got beyond what they've taught him in college (not much I suppose) - he claims developers are still writing directly to win32 api.

Dunno, but he must be living really, really deep in the cave as developers have been using higher level, object oriented libraries for like a decade and more. I have no idea why this rubbish even gets on the front page (ok I know, it bashes Windows and we like to do that, right comrades?)
Now win32 is exactly the same rubbish as posix, they are both basically just C style functions.. there is no object-oriented design because it was designed long ago, when processor cycles mattered more than today and if they really wanted to waste those cycles they could easily wrote whole damn OS in python. Efficiency, it matters. Now stupid developer (or library writer) will use win32, but a smart developer will rather choose libraries like wxWidgets, MFC or even Java or .NET.

And it's just plain lunacy to say .NET is insufficient. It is the best strongly typed framework, its C# is java 2.0, you can even fuse machine code(x86) into the same binary with C++\CLI and get flexibility and raw power of C++ to do just anything.

He also seems to be very quiet about some of the new stuff in .net languages like linq - or APIs like WPF, which is IMO just the most powerful gui creation library (and by that I mean this - this and this), but unfortuantely only available on windows.
So yeah, I'd say the author has completely no idea what he's talking about..

I just checked on the Atsiv issue there. Microsoft did not revoke the Atsiv certificate, they bludgeoned Verisign into doing so. Microsoft also maintains a revocation list of "blacklisted" SPCs in the kernel itself, which only applies to Kernel Mode drivers. Ordinary drivers don't seem to have a revocation method.

They also added Atsiv to Windows Defender as a malware utility, so it up and removed it from client PCs.

In no case do you actually need Microsoft to do anything - you sign your own driver with your own certificate which you bought independently from any of these companies.

You should get one with Microsoft Quirrell. Sorry, I mean Microsoft Sideshow

I agree, $3500 is insane for MSDN (I cap its value at $2,000), and I think the Premium Uber MSDN with Team System costs like $11,000. And the Express editions of Studio just don't cut it for a lot of people; no source control or unit testing, etc. Still, there's a middle ground:

Microsoft Certified Partners are entitled to a certain number of MSDN subscriptions and/or Visual Studio copies, depending on their partner level. Even as just a Registered Partner (anyone can get this simply by signing up for free), there's something called an Action Pack, I think, that includes enough licenses to get a small business running - server OS, SQL Server, etc. The Action Pack costs either $200 or $400, and I'm too lazy to verify that but here's the link if you're still interested:

http://partner.microsoft.com/

Getting Certified Partner status isn't a big hurdle; get some customer references and prove certain technologies are within your scope and you're well on your way.

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 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 was new for Windows 2000, which is already over 8 years old.

Also, as has already been mentioned here, the article omits WPF, 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. ;-)

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 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 was new for Windows 2000, which is already over 8 years old.

Also, as has already been mentioned here, the article omits WPF, 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. ;-)

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 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 was new for Windows 2000, which is already over 8 years old.

Also, as has already been mentioned here, the article omits WPF, 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. ;-)

Check out the free versions of Microsoft's development tools sometime, called Visual Studio Express editions. AFAIK, they can be used by enterprise developers for free as well, check out the license. I guess, it's because they're supposed to be "appetizers" for "the real things". But they work quite well, if you don't demand too much.

The Windows SDK is also a free download, containing the full OS documentation, build environments and samples.

IMNSHO, that's just a non-issue to claim that development for Windows would be expensive.

Besides, there are other good, free development tools for Windows, like Watcom C/C++ (which is BTW the only compiler natively supporting DOS, Win 3.1, Win32, OS/2, and NLM development, with Linux support planned LTIC).

Free IDEs for .NET development include Eclipse, and others.

Check out the free versions of Microsoft's development tools sometime, called Visual Studio Express editions. AFAIK, they can be used by enterprise developers for free as well, check out the license. I guess, it's because they're supposed to be "appetizers" for "the real things". But they work quite well, if you don't demand too much.

The Windows SDK is also a free download, containing the full OS documentation, build environments and samples.

IMNSHO, that's just a non-issue to claim that development for Windows would be expensive.

Besides, there are other good, free development tools for Windows, like Watcom C/C++ (which is BTW the only compiler natively supporting DOS, Win 3.1, Win32, OS/2, and NLM development, with Linux support planned LTIC).

Free IDEs for .NET development include Eclipse, and others.

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

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.