I hear that all too often. Personally, I think sense of entitlement has already done enough damage to IT security: there is this whole cottage industry of blackmailing services thriving on it, and despite it paying part of my rent, it only feels right and just to sabotage it.
I would have made the patch for myself anyway (it wouldn't have been the first), releasing it as open source was just the icing. I didn't do it for any particular reason other than the obvious: I want to be protected, and I can protect myself
It's a memory-only patch, and it hooks the vulnerable function using a standard, documented method (that was made obsolescent in Vista, but Vista isn't vulnerable in the first place). Apart from the horrible bugs that are entirely my own damn fault, nobody will care or know that my patch is installed on a system (unless they go look for it). It doesn't even address the vulnerability directly, it just prevents the vulnerable function from ever seeing an abnormal URL. Basically, I did it because I could, and because I wanted to: I knew how to hook in ShellExecuteEx, but I needed some hands-on experience with it
Aside: I'm not even 100% sure of where the vulnerability is, yet, but I think the single bad choice that breaks the camel's back is an error handling function believing an error of "invalid argument" (returned by Internet Explorer 7 for malformed URLs) is not a critical error, allowing the URL to be misidentified as a non-normalized file path. The bug has been sleeping there since, I think, Internet Explorer 6, but it wasn't until Internet Explorer 7 that URL handling for execution purposes was moved from shdocvw.dll (and, I presume, the ParseURL routine, which is very liberal and only really serves to carve the scheme out of an URL) to ieframe.dll (and either the InternetCrackUrl or CoInternetParseUrl routine, which are a lot more finicky about URL syntax)
Lastly: for developers, I have made a little snippet of code that demonstrates how to safely and unambiguously execute an URL with ShellExecute(Ex) without risking its interpretation as something else (yes, it would have prevented this mess), and documents a few other subtleties. For now it's just another post on Full Disclosure, I will give it a better home one day. I wish Mozilla used something like this instead of the messy code they have now
Windows supports EFI. Here, now, today. Has been for years. Currently is. Except only on the IA64 architecture. This makes the article partly bullshit, and a large amount of comments here as well. But the bullshit doesn't stop here.
Of course the thing about drivers being stored entirely in EFI is completely false, misleading and somewhat retarded (it really depends on how twisted your idea of drivers is. If you come from a Linux background there's a 9 in 10 chance you are clueless and forever jaded about it). Of course the DRM comments here don't make the slightest sense, since TPM chips are here, now, have been for years, and they work with the old, usual, actually-existing BIOS extensibility interface (i.e.: drop a function pointer somewhere, get called). Have you bought an IBM laptop or workstation that was made some time after the Cretacean? congratulations! your cute little black box is Trusted Computing compliant (r), (c) and (TM)!
From a more technical point of view: Windows doesn't depend on legacy hardware. It used to, in ye olden days (until before Windows Server 2003 R1), but it was so easy to get around it with software emulators (provided by Microsoft herself, as part of Windows NT 4 Embedded, Server Appliance Kit for Windows 2000 Server, et cetera) that only people with a really small penis complained. Nowadays it's a matter of the right boot loader and Hardware Abstraction Layer (all aboard the cluetraaain! if you are among the differently-endowed mouth breathers who confuse "instruction set" with "hardware" - and you know if you are one - this might just be your chance to finally get it!).
Technical trivia: the Windows boot loader is a beauty. It totally mops the floor with anything in the wild, save maybe for Grub. The horrid ntldr flat executable is just a teeny weeny stub containing the real thing, a PE executable called osloader.exe (with a resource section, even - the description simply says "Boot loader"; sadly it has no icon) which is the universal loader - why, yes, your humble peecee can network-boot too! In short, the little bugger comes with a full SCSI+ATAPI stack (it can even stay loaded and be used by the kernel as the SCSI class driver - no shit!), a network stack for the TFTP client (yep) and its very own hardware abstraction layer, since the thing was written against ARC (think EFI, only for the Alpha AXP architecture) which is only really available on Alpha. The thing is a driver model short of a full operating system
So, reconsider the length of your penis in the light of these new facts
[...]
but why are there no controls to go back and forth?
Don't know what you're talking about. Opera's fast forward worked, so there must have been a link saying "next" somewhere in the page. Ah, and I think all of the hacks are pretty cool (in a "grin" sort of way, in some cases - cryo-lego-mouse anyone?), they sure beat my corny "USB Christmas tree" idea:-)
Windows applications are not legacy. Linux is not a Windows replacement. BSD neither. We are totally, absolutely, positively sure: it's a Windows clone we want. We don't all secretly dream running Linux, and in fact several of us must fight the puke back when forced to deal with it (except KDE. I like KDE. I'd like it even more if it ran under Windows). Some have had their weird ideas phase, but you get over it soon.
We're tired of hearing about this every damn time, and I'm not speaking personally here. Even the Linux users among the developers are fed up with that argument. It doesn't make sense, ReactOS is real, is here, today: deal with it already, because at the point it is now, it's not just going to go away.
Your technical argument doesn't make sense, either. One of such DLLs you talk of is called "the Windows kernel", and it's a pretty big piece of software (a 2+ MB binary, for the record). And it has a private API to talk to the HAL. And one to the authentication service. And another to the event logging service. And yet another to the PNP service. Each of these services can be queried by applications with an undocumented RPC protocol. It's a recurring theme in Windows: most APIs have two sides with unknown grounds in the middle, and many DLLs expose multiple client sides. Picture the graph in your mind. No, more arcs. No, way more than that. Yes, you're getting closer, and yes, that arc does go twice the same way. Etc.
One has to wonder why couldn't Wine just provide a loader for Windows executables and let the (air quotes) D-L-L-s (air quotes) do the rest, if your statement had even the slightest trace of truth in it.
Please don't trivialize our work, which is something you apparently don't fathom in the slightest
I believe this is pretty much what happened with ReactOS (I'm not a ReactOS developer), so I wouldn't hold it against the current crowd too much.
ReactOS was born in dark, barbaric times. In 1997, your most realistic option to build PE executables with GCC on Windows was DJGPP, the port of GCC to a DOS extender, because MinGW didn't exist yet. I have had the dubious privilege of trying that - when I joined the project, DJGPP was no longer required for the main tree, but the boot loader still had to be built with it.
Also, the "don't design, code!" attitude worked in the beginning, to get anything done and avoid the mistake of the ReactOS father, FreeWin95, forever stuck in the design phase, but it backfired when real stuff began to run. It just doesn't work when cloning a system as firmly established as Windows - you can't always attack the problems by implementing function after function, many times you need a good overhead view. The short of it is that we have some embarassingly bad code in the kernel.
Personally, I think most of the talent in Linux is wasted and should go into the underappreciated FreeBSD, but that could be just me. Then, Wine on Linux has limits. The Wine people know this, we know this, and we're trying to meet in the middle
Ironically, what the project lacks isn't generical operating system development skills that could be converted for another system (and does such a thing exist, anyway?), it's precisely the Windows-specific skills of a certain level, the familiarity with all the quirks and hacks that turn every driver test on ReactOS into a deadlock-memory-corruption-bugcheck fest. Sadly, all Windows experts seem to be either somehow involved with Microsoft (like one of our former developers) or total cocks with a contempt for everything open source.
You're confusing ReactOS with WinuxOS (rejected Slashdot story, complaint ignored by SourceForge administrators - note how they even ripped off our mission statement). ReactOS exists since 1997 and has been written from the ground up
ReactOS is Wine - everything Wine has, ReactOS has too, except the Linux-specific parts (that, in ReactOS, will be handled by drivers). And ReactOS does implement recent APIs, we're no way stuck with Windows NT 4 compatibility, in fact our current baseline is more like Windows 2000 (especially true for the kernel). Finally, we won't just get up one day and declare 1.0: it will be 1.0 when compatibility reaches the intended milestone for 1.0 (namely, good enough to replace somewhere between Windows NT 4 Workstation and Windows 2000 Professional)
GCC is included in Interix because it's the only compiler that can make UNIX-style executables in PE/COFF format, and because most applications either explicitely require GCC or require shared objects. But Microsoft doesn't use GCC for the tools that weren't originally GNU (most aren't, they come from some BSD), and GCC and GNU are optional components, not included in a standard installation
Yeah, that must be why all of Microsoft's software can install and run under any account (their packages even default to My Documents as the destination of single-user installs). Since you mention ActiveDirectory, you can use AD to publish your applications to groups or OUs - as soon as anyone tries to run a published program that isn't installed on their workstation, it gets installed automatically, for the whole workstation and whatever the kind of user that started the program in the first place
Well, I didn't see any heads rolling for this, so don't hold your breath. Yes, it is a project based in Eastern Europe for an illegal Windows 2000 distribution compiled from the leaked sources. Yes, it's on SourceForge. Yes, I did report this to the SourceForge administrators. And yes, it's still there
Sorry, but this statement is straight up false. The WinCE kernel is based off of the Windows NT 4.0 kernel. Also, WinCE shares the architecture of Windows 2000.
hahahahaha! wait, you're serious - HAHAHAHAHAHAHAHAHAHA! Windows CE shares absolutely nothing with Windows - not even the system DLLs are called the same. Let's see...
Windows CE is a shared-memory microkernel (the kernel is a process, and every thread migrates to it during system calls) with an object-oriented kernel and a real-time scheduler, developed to implement a small subset of Win32 (it doesn't even have drive letters!)
Windows NT is a protected-memory monolithic kernel with vague microkernel nuances, a pretty rigid kernel (pretty much only allowing filesystem filter driver as a means of extending it) and a very traditional scheduler (round-robin, 32 priority levels), designed to implement nearly any OS API known to man (various kernel features exist solely for DOS, Win32 and POSIX support) and its own original API ("native API")
I'd be surprised if they even shared the SDK header files
One of the design goals was to be platform independent, hence the HAL
Don't confuse the DirectX HAL with the HAL proper. The HAL used by the Windows kernel isn't for independence from a particular instruction set (i.e. x86 vs PPC vs MIPS etc.) - the system design and the reduced use of assembly take care of that. The HAL is for independence from hardware, meant as the physical implementation of an instruction set
For example, an SGI workstation and the Playstation are both MIPS (same instruction set), but the hardware is deeply different (so a hypothetical Windows NT for MIPS would use the same kernel for both but a different HAL for each)
More mundane examples, in the x86 world, are ACPI vs standard PC (where the HAL abstracts how to send certain commands to the hardware), or uniprocessor vs SMP (where the HAL abstracts the spinlock implementation, respectively "disable multitasking" and "spin on an integer"). And, just for the record, what the "choose computer type" hidden dialog at the beginning of the Windows setup lets you do is choosing a HAL manually
BTW, thanks a fucking lot, Microsoft Office team. Next time, use the fucking redistributable like everyone else, please: maybe we'd have KB articles with an "Applies to" section that doesn't read like "War and peace"
No, that's the vital point you missed: Word documents are OLE compound storage documents ("docfiles"). Essentially, structured mini-filesystems. Microsoft even wrote a NTFS plugin (reparse point handler), during the Windows 2000 public beta (one of several plugins developed to show off the new features of NTFS to filesystem filter developers), that expanded docfiles into directories. The reason you don't say a lot of this is that the filesystem driver SDK costs $ 1500 and involves an NDA - and that Microsoft would rather sell you the whole thing as a product apart
I've tried it. It sucks. The stick doesn't move far enough, so it's impossible to calibrate the speed of scrolling. And I like it that the scroll wheel has notches (even though they tend to wear out pretty fast...)
An XML document in the Winamp skin zip file can reference a HTML document using the "browser" tag and get it to run in the "Local computer zone"
Do you see the problem here? Winamp embeds the whole Internet Explorer application, not just the HTML rendering control. That's rarely a good idea, since you effectively lose control over your own application - for example, Winamp is "restricted" by the Internet Explorer policies based on zones, instead of disabling active content period
Multi-Language: Please, they're all the same language designed to look like other languages
Sure, C# and Visual Basic share a lot, but they're the odd ones. See F#, COBOL.NET, Managed Extensions for C++ and the excellent Managed C++ in the works
Java has multi language support to (Jython). This is not a fundamental reason.
Java has poor abstractions, and is based too much on the fallacious "less syntax, more library" principle. Java is the C of managed environments. Sure, you can compile anything into it, but that's just because it's Turing-complete. Must be a lot of fun implementing any useful compiler without delegates and value types
Value Types: Use escape analysis and a better GC. This is a hack so programmers can give hints to a stupid GC.
Value types aren't garbage-collected at all. And they are important for performance and interoperability. Oh, and the.NET GC does pretty fine, thank you. Whidbey will even let you allocate managed objects on the native heap, and native objects on the managed heap. And you can't do that in C#, this is an uber-geek feature designed for Managed C++, that only further underlines the multi-language and multi-paradigm goal of.NET. Java, in its arrogant engineered "perfection", will never get actually useful stuff like this. Useful how? it gives you a GC heap for free to allocate your own objects on. It lets you use managed objects with the STL, or the excellent Boost. Or use a different GC, like Hans Boehm's, if you don't like.NET's (in fact, the syntax for Managed C++ has been designed with the goal of not conflicting - or even overlapping features - with any of the major C++ frameworks). Without writing a single line of glue code in C
Generics: Where are the C# generics? The version we're using at work doesn't have them.
Java Generics will arrive first, but be worse off in the beginnnig.
It doesn't matter, because they are a lie. And Java only got them because.NET did
C# language: The only even marginally valid claim. However, the lack of checked exceptions
Microsoft maintains a longeve C++ compiler: they've been there, done that. They never believed in checked exceptions. Nowadays they are mostly agreed with. By all means, look for Herb Sutter's site: like most Microsoft techies with blogs, he gives no-nonsense explanations of all the design choices he's been involved with, and that includes checked exceptions and lack thereof
Bad examples. All of the NIC configuration tasks can be carried out with netsh (it's under-documented, but it tends to be very self-explainatory, thanks to the built-in help of commands and the concept of contexts), and the route command is native and works basically the same. Installing Apache, Ethereal and NetCat covers the other cases
The history-completion in the console is mainly accessed with the F8 key, plus others I don't recall at the moment. It's a function of the console itself, meaning any program reading line-based console input immediately benefits from it. Unfortunately, the history is volatile, probably due to the console manager being implemented in what can be best described as an "user-mode kernel" (an uncomfortable heritage from the original microkernel design). The inability of launching commands in the background is a small hole in the Windows console model, but for most practical purposes the start command can replace it.
And, while you mention it, the net command is the LanManager/NetBIOS client (actually, the client is the LanmanWorkstation service - a "client server"?), but it's somewhat dated and doesn't expose all the features of the LanMan API (like not allowing to execute certain commands on remote machines). It has some additional and useful sub-commands as well, like net helpmsg, which decodes the cryptic error codes sometimes found in logs and message boxes, and net start/stop, to control services (altough I recommend the sc command for that, albeit unintuitive and cryptic to non-developers)
You look at Windows and you think "past" and "legacy". We (ReactOS) look at Windows and think "future" and "innovation"
This you say is (my personal opinion, not the project's official position), a lot like people deluding themselves in thinking that a Linux kernel for the next Windows would mean instant improvement. If you knew a bit more about Windows you'd knew it doesn't even make sense - the Windows kernel has proved to be a sound design and I'd be happy if we could at least duplicate it. It's the system services that need a serious redesign, dragging the legacy microkernel corpse as they are, and I'm already doing some research in that direction (currently reimplementing the console model to be driver-based instead of server-based, and allowing custom UI implementations. This will give you, the user, custom terminal emulators, a more efficient SSH server and a job-controlling shell - even a port of your beloved GNU screen. Next stop: overhauling the service manager and rationalizing the user-mode startup sequence)
And please realize that a supposed intrinsic and purely technical superiority of Linux exists almost entirely in your mind - old kernels (2.4 and earlier) weren't that hot, and when you say "Linux" you generally mean "GNU" (those who say "Linux" meaning "Beowulf" or "OpenMOSIX" are the minority) - and realize that "commodity" also means "largely irrelevant" and "expendable" - when ReactOS gets good enough, it could replace even Linux for some people
Try out the Windows Application Compatibility Toolkit, in particular the Application Verifier, which helps you diagnose problems in badly written programs, and the Compatibility Administrator, which fixes said problems when the vendor is unresponsive and/or you aren't in the position of fixing the application yourself (you have to see to believe). Windows already comes with a large database of known probems and runtime patches ("shims"), and Microsoft has to accept suggestions for additions to the database (didn't try myself) as many applications are added in each Service Pack. Unfortunately, however, the API for shim DLLs has not been published yet, so if you can't find the right fix in the database you're on your own.
Random technical note: the shim engine is started by user32.dll, so you can't patch programs that don't import it. Of Win32 applications, only pure ANSI C programs compiled with Visual C++ fit this profile, AFAIK, and I haven't seen many (example: the bzip2 port for Windows). On the other hand, I think it could be made possible by applying the "propagate shim engine" patch to Winlogon.exe
Slashdot Mirror
I hear that all too often. Personally, I think sense of entitlement has already done enough damage to IT security: there is this whole cottage industry of blackmailing services thriving on it, and despite it paying part of my rent, it only feels right and just to sabotage it.
I would have made the patch for myself anyway (it wouldn't have been the first), releasing it as open source was just the icing. I didn't do it for any particular reason other than the obvious: I want to be protected, and I can protect myself
It's a memory-only patch, and it hooks the vulnerable function using a standard, documented method (that was made obsolescent in Vista, but Vista isn't vulnerable in the first place). Apart from the horrible bugs that are entirely my own damn fault, nobody will care or know that my patch is installed on a system (unless they go look for it). It doesn't even address the vulnerability directly, it just prevents the vulnerable function from ever seeing an abnormal URL. Basically, I did it because I could, and because I wanted to: I knew how to hook in ShellExecuteEx, but I needed some hands-on experience with it
Aside: I'm not even 100% sure of where the vulnerability is, yet, but I think the single bad choice that breaks the camel's back is an error handling function believing an error of "invalid argument" (returned by Internet Explorer 7 for malformed URLs) is not a critical error, allowing the URL to be misidentified as a non-normalized file path. The bug has been sleeping there since, I think, Internet Explorer 6, but it wasn't until Internet Explorer 7 that URL handling for execution purposes was moved from shdocvw.dll (and, I presume, the ParseURL routine, which is very liberal and only really serves to carve the scheme out of an URL) to ieframe.dll (and either the InternetCrackUrl or CoInternetParseUrl routine, which are a lot more finicky about URL syntax)
Lastly: for developers, I have made a little snippet of code that demonstrates how to safely and unambiguously execute an URL with ShellExecute(Ex) without risking its interpretation as something else (yes, it would have prevented this mess), and documents a few other subtleties. For now it's just another post on Full Disclosure, I will give it a better home one day. I wish Mozilla used something like this instead of the messy code they have now
Windows supports EFI. Here, now, today. Has been for years. Currently is. Except only on the IA64 architecture. This makes the article partly bullshit, and a large amount of comments here as well. But the bullshit doesn't stop here.
Of course the thing about drivers being stored entirely in EFI is completely false, misleading and somewhat retarded (it really depends on how twisted your idea of drivers is. If you come from a Linux background there's a 9 in 10 chance you are clueless and forever jaded about it). Of course the DRM comments here don't make the slightest sense, since TPM chips are here, now, have been for years, and they work with the old, usual, actually-existing BIOS extensibility interface (i.e.: drop a function pointer somewhere, get called). Have you bought an IBM laptop or workstation that was made some time after the Cretacean? congratulations! your cute little black box is Trusted Computing compliant (r), (c) and (TM)!
From a more technical point of view: Windows doesn't depend on legacy hardware. It used to, in ye olden days (until before Windows Server 2003 R1), but it was so easy to get around it with software emulators (provided by Microsoft herself, as part of Windows NT 4 Embedded, Server Appliance Kit for Windows 2000 Server, et cetera) that only people with a really small penis complained. Nowadays it's a matter of the right boot loader and Hardware Abstraction Layer (all aboard the cluetraaain! if you are among the differently-endowed mouth breathers who confuse "instruction set" with "hardware" - and you know if you are one - this might just be your chance to finally get it!).
Technical trivia: the Windows boot loader is a beauty. It totally mops the floor with anything in the wild, save maybe for Grub. The horrid ntldr flat executable is just a teeny weeny stub containing the real thing, a PE executable called osloader.exe (with a resource section, even - the description simply says "Boot loader"; sadly it has no icon) which is the universal loader - why, yes, your humble peecee can network-boot too! In short, the little bugger comes with a full SCSI+ATAPI stack (it can even stay loaded and be used by the kernel as the SCSI class driver - no shit!), a network stack for the TFTP client (yep) and its very own hardware abstraction layer, since the thing was written against ARC (think EFI, only for the Alpha AXP architecture) which is only really available on Alpha. The thing is a driver model short of a full operating system
So, reconsider the length of your penis in the light of these new facts
Don't know what you're talking about. Opera's fast forward worked, so there must have been a link saying "next" somewhere in the page. Ah, and I think all of the hacks are pretty cool (in a "grin" sort of way, in some cases - cryo-lego-mouse anyone?), they sure beat my corny "USB Christmas tree" idea :-)
Windows applications are not legacy. Linux is not a Windows replacement. BSD neither. We are totally, absolutely, positively sure: it's a Windows clone we want. We don't all secretly dream running Linux, and in fact several of us must fight the puke back when forced to deal with it (except KDE. I like KDE. I'd like it even more if it ran under Windows). Some have had their weird ideas phase, but you get over it soon.
We're tired of hearing about this every damn time, and I'm not speaking personally here. Even the Linux users among the developers are fed up with that argument. It doesn't make sense, ReactOS is real, is here, today: deal with it already, because at the point it is now, it's not just going to go away.
Your technical argument doesn't make sense, either. One of such DLLs you talk of is called "the Windows kernel", and it's a pretty big piece of software (a 2+ MB binary, for the record). And it has a private API to talk to the HAL. And one to the authentication service. And another to the event logging service. And yet another to the PNP service. Each of these services can be queried by applications with an undocumented RPC protocol. It's a recurring theme in Windows: most APIs have two sides with unknown grounds in the middle, and many DLLs expose multiple client sides. Picture the graph in your mind. No, more arcs. No, way more than that. Yes, you're getting closer, and yes, that arc does go twice the same way. Etc.
One has to wonder why couldn't Wine just provide a loader for Windows executables and let the (air quotes) D-L-L-s (air quotes) do the rest, if your statement had even the slightest trace of truth in it.
Please don't trivialize our work, which is something you apparently don't fathom in the slightest
ReactOS was born in dark, barbaric times. In 1997, your most realistic option to build PE executables with GCC on Windows was DJGPP, the port of GCC to a DOS extender, because MinGW didn't exist yet. I have had the dubious privilege of trying that - when I joined the project, DJGPP was no longer required for the main tree, but the boot loader still had to be built with it.
Also, the "don't design, code!" attitude worked in the beginning, to get anything done and avoid the mistake of the ReactOS father, FreeWin95, forever stuck in the design phase, but it backfired when real stuff began to run. It just doesn't work when cloning a system as firmly established as Windows - you can't always attack the problems by implementing function after function, many times you need a good overhead view. The short of it is that we have some embarassingly bad code in the kernel.
Personally, I think most of the talent in Linux is wasted and should go into the underappreciated FreeBSD, but that could be just me. Then, Wine on Linux has limits. The Wine people know this, we know this, and we're trying to meet in the middle
Ironically, what the project lacks isn't generical operating system development skills that could be converted for another system (and does such a thing exist, anyway?), it's precisely the Windows-specific skills of a certain level, the familiarity with all the quirks and hacks that turn every driver test on ReactOS into a deadlock-memory-corruption-bugcheck fest. Sadly, all Windows experts seem to be either somehow involved with Microsoft (like one of our former developers) or total cocks with a contempt for everything open source.
That, and some of us really, really hate Linux.
You're confusing ReactOS with WinuxOS (rejected Slashdot story, complaint ignored by SourceForge administrators - note how they even ripped off our mission statement). ReactOS exists since 1997 and has been written from the ground up
ReactOS is Wine - everything Wine has, ReactOS has too, except the Linux-specific parts (that, in ReactOS, will be handled by drivers). And ReactOS does implement recent APIs, we're no way stuck with Windows NT 4 compatibility, in fact our current baseline is more like Windows 2000 (especially true for the kernel). Finally, we won't just get up one day and declare 1.0: it will be 1.0 when compatibility reaches the intended milestone for 1.0 (namely, good enough to replace somewhere between Windows NT 4 Workstation and Windows 2000 Professional)
GCC is included in Interix because it's the only compiler that can make UNIX-style executables in PE/COFF format, and because most applications either explicitely require GCC or require shared objects. But Microsoft doesn't use GCC for the tools that weren't originally GNU (most aren't, they come from some BSD), and GCC and GNU are optional components, not included in a standard installation
Yeah, that must be why all of Microsoft's software can install and run under any account (their packages even default to My Documents as the destination of single-user installs). Since you mention ActiveDirectory, you can use AD to publish your applications to groups or OUs - as soon as anyone tries to run a published program that isn't installed on their workstation, it gets installed automatically, for the whole workstation and whatever the kind of user that started the program in the first place
Well, I didn't see any heads rolling for this, so don't hold your breath. Yes, it is a project based in Eastern Europe for an illegal Windows 2000 distribution compiled from the leaked sources. Yes, it's on SourceForge. Yes, I did report this to the SourceForge administrators. And yes, it's still there
hahahahaha! wait, you're serious - HAHAHAHAHAHAHAHAHAHA! Windows CE shares absolutely nothing with Windows - not even the system DLLs are called the same. Let's see...
Windows CE is a shared-memory microkernel (the kernel is a process, and every thread migrates to it during system calls) with an object-oriented kernel and a real-time scheduler, developed to implement a small subset of Win32 (it doesn't even have drive letters!)
Windows NT is a protected-memory monolithic kernel with vague microkernel nuances, a pretty rigid kernel (pretty much only allowing filesystem filter driver as a means of extending it) and a very traditional scheduler (round-robin, 32 priority levels), designed to implement nearly any OS API known to man (various kernel features exist solely for DOS, Win32 and POSIX support) and its own original API ("native API")
I'd be surprised if they even shared the SDK header files
Don't confuse the DirectX HAL with the HAL proper. The HAL used by the Windows kernel isn't for independence from a particular instruction set (i.e. x86 vs PPC vs MIPS etc.) - the system design and the reduced use of assembly take care of that. The HAL is for independence from hardware, meant as the physical implementation of an instruction set
For example, an SGI workstation and the Playstation are both MIPS (same instruction set), but the hardware is deeply different (so a hypothetical Windows NT for MIPS would use the same kernel for both but a different HAL for each)
More mundane examples, in the x86 world, are ACPI vs standard PC (where the HAL abstracts how to send certain commands to the hardware), or uniprocessor vs SMP (where the HAL abstracts the spinlock implementation, respectively "disable multitasking" and "spin on an integer"). And, just for the record, what the "choose computer type" hidden dialog at the beginning of the Windows setup lets you do is choosing a HAL manually
BTW, thanks a fucking lot, Microsoft Office team. Next time, use the fucking redistributable like everyone else, please: maybe we'd have KB articles with an "Applies to" section that doesn't read like "War and peace"
Microsoft Security Bulletins RSS feed, to receive notifications of new patches ASAP
MBSA and HFNetChk, automated tools to check if your system is up to date (see also the qfecheck command to check the status of installed patches)
Windows Update: analyze and update your system from a web page
Microsoft Systems Management Server (prices and licensing), a solution for the management of Windows networks. Comes with support for automated deploying of patches
No, that's the vital point you missed: Word documents are OLE compound storage documents ("docfiles"). Essentially, structured mini-filesystems. Microsoft even wrote a NTFS plugin (reparse point handler), during the Windows 2000 public beta (one of several plugins developed to show off the new features of NTFS to filesystem filter developers), that expanded docfiles into directories. The reason you don't say a lot of this is that the filesystem driver SDK costs $ 1500 and involves an NDA - and that Microsoft would rather sell you the whole thing as a product apart
I've tried it. It sucks. The stick doesn't move far enough, so it's impossible to calibrate the speed of scrolling. And I like it that the scroll wheel has notches (even though they tend to wear out pretty fast...)
Do you see the problem here? Winamp embeds the whole Internet Explorer application, not just the HTML rendering control. That's rarely a good idea, since you effectively lose control over your own application - for example, Winamp is "restricted" by the Internet Explorer policies based on zones, instead of disabling active content period
In other news, the ability to execute programs leaves you open to malware. The hole is in the article author's head
Sure, C# and Visual Basic share a lot, but they're the odd ones. See F#, COBOL.NET, Managed Extensions for C++ and the excellent Managed C++ in the works
Java has poor abstractions, and is based too much on the fallacious "less syntax, more library" principle. Java is the C of managed environments. Sure, you can compile anything into it, but that's just because it's Turing-complete. Must be a lot of fun implementing any useful compiler without delegates and value types
Value types aren't garbage-collected at all. And they are important for performance and interoperability. Oh, and the .NET GC does pretty fine, thank you. Whidbey will even let you allocate managed objects on the native heap, and native objects on the managed heap. And you can't do that in C#, this is an uber-geek feature designed for Managed C++, that only further underlines the multi-language and multi-paradigm goal of .NET. Java, in its arrogant engineered "perfection", will never get actually useful stuff like this. Useful how? it gives you a GC heap for free to allocate your own objects on. It lets you use managed objects with the STL, or the excellent Boost. Or use a different GC, like Hans Boehm's, if you don't like .NET's (in fact, the syntax for Managed C++ has been designed with the goal of not conflicting - or even overlapping features - with any of the major C++ frameworks). Without writing a single line of glue code in C
Whidbey (.NET 2.0). Also previewed in Rotor
It doesn't matter, because they are a lie. And Java only got them because .NET did
Microsoft maintains a longeve C++ compiler: they've been there, done that. They never believed in checked exceptions. Nowadays they are mostly agreed with. By all means, look for Herb Sutter's site: like most Microsoft techies with blogs, he gives no-nonsense explanations of all the design choices he's been involved with, and that includes checked exceptions and lack thereof
Bad examples. All of the NIC configuration tasks can be carried out with netsh (it's under-documented, but it tends to be very self-explainatory, thanks to the built-in help of commands and the concept of contexts), and the route command is native and works basically the same. Installing Apache, Ethereal and NetCat covers the other cases
The history-completion in the console is mainly accessed with the F8 key, plus others I don't recall at the moment. It's a function of the console itself, meaning any program reading line-based console input immediately benefits from it. Unfortunately, the history is volatile, probably due to the console manager being implemented in what can be best described as an "user-mode kernel" (an uncomfortable heritage from the original microkernel design). The inability of launching commands in the background is a small hole in the Windows console model, but for most practical purposes the start command can replace it.
And, while you mention it, the net command is the LanManager/NetBIOS client (actually, the client is the LanmanWorkstation service - a "client server"?), but it's somewhat dated and doesn't expose all the features of the LanMan API (like not allowing to execute certain commands on remote machines). It has some additional and useful sub-commands as well, like net helpmsg, which decodes the cryptic error codes sometimes found in logs and message boxes, and net start/stop, to control services (altough I recommend the sc command for that, albeit unintuitive and cryptic to non-developers)
You look at Windows and you think "past" and "legacy". We (ReactOS) look at Windows and think "future" and "innovation"
This you say is (my personal opinion, not the project's official position), a lot like people deluding themselves in thinking that a Linux kernel for the next Windows would mean instant improvement. If you knew a bit more about Windows you'd knew it doesn't even make sense - the Windows kernel has proved to be a sound design and I'd be happy if we could at least duplicate it. It's the system services that need a serious redesign, dragging the legacy microkernel corpse as they are, and I'm already doing some research in that direction (currently reimplementing the console model to be driver-based instead of server-based, and allowing custom UI implementations. This will give you, the user, custom terminal emulators, a more efficient SSH server and a job-controlling shell - even a port of your beloved GNU screen. Next stop: overhauling the service manager and rationalizing the user-mode startup sequence)
And please realize that a supposed intrinsic and purely technical superiority of Linux exists almost entirely in your mind - old kernels (2.4 and earlier) weren't that hot, and when you say "Linux" you generally mean "GNU" (those who say "Linux" meaning "Beowulf" or "OpenMOSIX" are the minority) - and realize that "commodity" also means "largely irrelevant" and "expendable" - when ReactOS gets good enough, it could replace even Linux for some people
Try out the Windows Application Compatibility Toolkit, in particular the Application Verifier, which helps you diagnose problems in badly written programs, and the Compatibility Administrator, which fixes said problems when the vendor is unresponsive and/or you aren't in the position of fixing the application yourself (you have to see to believe). Windows already comes with a large database of known probems and runtime patches ("shims"), and Microsoft has to accept suggestions for additions to the database (didn't try myself) as many applications are added in each Service Pack. Unfortunately, however, the API for shim DLLs has not been published yet, so if you can't find the right fix in the database you're on your own.
Random technical note: the shim engine is started by user32.dll, so you can't patch programs that don't import it. Of Win32 applications, only pure ANSI C programs compiled with Visual C++ fit this profile, AFAIK, and I haven't seen many (example: the bzip2 port for Windows). On the other hand, I think it could be made possible by applying the "propagate shim engine" patch to Winlogon.exe
Ooops. Replace all occurrences of "pizza_order" with "pizza_party"