Umm in most places they are illegal*. For example in Hawaii (which is part of the 9th circuit, which is the same on as mentioned in this article.) steroids are considered a 'harmful drug' and possession of any amount is a misdemeanor.

*: Assuming you mean 'real' steroids and not those used for asthma and so forth. Also there is a huge cat-and-mouse game with law-makers and steroid-makers, law-makers ban substance X, steroid makers tweak it slightly so it does the same thing, but it has a slightly different chemical structure, so law markers ban that one, and so forth. But the law-markers bannings take a long time to do, so any one substance might be legal for a while.

That's more or less it. That of course combined with a massive ego so the guy probably believes that nobody could really disagree with him, so if it seems like a lot of people they all must be the same moron. Of course this admin didn't bother telling me I was being investigated either. The investigation was closed after two weeks with the option to reopen for lack of evidence. So I'm still partially presumed guilty.

Take a world map, throw a dart...

Unless he's black, Polish, Romani, homosexual or disabled.

Not that Stalin was any better, but Hitler most certainly didn't killed only Jews.

Yeah, I tried the linked proof of concept on the RELEASED version of Windows 7 (the site only references beta and RC versions), and it didn't work. Either it prompted, or it failed to acquire admin or high integrity rights. I notice the site hasn't been updated for build 7600 (the RTM version), even though it's been available for some time. Even if MS patched the specific thing the proof of concept was using but failed to fix the underlying problem, they still need to release an updated version to be taken seriously. The fact that pre-release versions of Windows 7 were incomplete is hardly surprising.

RootkitRevealer comes to mind. It compares filesystem and other system database binaries raw on disk to what's returned from system calls. No known rootkits are sophisticated enough to return fake filesystem structures from raw reads to match the filtering they do.

This line of argument boils down to an implication that something exists despite claims to the contrary, just because someone isn't looking for it in a certain way. There's no reason to think that certain way of looking is exhaustive or that conditions would make that thing likely to exist in the first place. How do you know that the Russian Mafia doesn't have your phones tapped without doing a daily bug sweep? Magical ninja bug detection powers, surely.

Here is a collection of references. See also Readers Write: How Microsoft got Windows NT, Everything2: The similarities between VMS and Windows NT and Windows NT and VMS: The Rest of the Story (use googlebot useragent to view full story).

DEC did sue Microsoft, but they settled for royalties.

Since Windows NT 3.1 (in 1993) it's been possible to lock a normal User down pretty tightly. Normal users can't infect the underlying system. It takes membership in the Administrator's group or certain privileges to do so.

Can you name a specific deficiency in system design that allows a normal user in any NT derived version of Windows to infect the system or other user accounts?

The reason that some games don't run properly as a normal user is because they are badly written or want to install kernel DRM/copy protection drivers. Games have always had access to the resources they would legitimately need to run.

Display drivers have always been allowed to store device associated bitmaps in video memory, and draw on them directly. However, you are right that the DWM model in Vista is better. It matches modern hardware much better than the old GDI model.

I thought the single window support was only in the server editions. I wasn't aware of the other features; those do sound quite useful.

I know anecdote wars are never very helpful, and I don't know what I have configured differently than you, but XP Wireless support has always just worked for me, at least post SP2 (when I've used it the most).

Not exactly sure what you're trying to say here. When a window in the XPDDM is redrawn (due to a WM_PAINT message being received), the request is only for the changed/newly visible section. Subsequent drawing to this area and the window area is clipped by region by GDI, which prevents anything outside the changed area inside the window from being painted on. XP and Vista/7 do have a mode where they will display the last image of an unresponsive window, greyed instead of ignoring paint commands (leaving a hall of mirrors effect). Many programs were already caching their window bitmaps privately, simply blitting to WM_PAINT request areas. For compatibility, Vista and 7 still have to send messages like WM_ERASEBKGND and WM_PAINT to applications in many cases, like having the window get focus or when moving partially off screen.

There is a little more power mgmt stuff, but I wouldn't call it "much better".

Windows NT has always supported GPU acceleration of the GUI through the display driver. The DWM just uses it differently, mostly for 3d effects and caching window contents.

What does this mean? DLLs have always been mapped COW in processes, and SXS was introduced in XP.

You can use the fancy aero and desktop composition effects in RDP6, in Vista, plus support for more device redirection. This is nice, but mainly eye candy. Not a vast improvement. There isn't much substantive that you can do with RDP 6.1 that you couldn't in 5.1. Or NT4 TSE for that matter.

Group policy, with MSI installation, net boot installation, etc. existed in their current form since Windows 2000. There have been improvements, but no vast revolutions.

XP had AMD64 support first (albeit with the WS2003 code base). The drivers are finally catching up. This is mainly the job of IHVs, not Microsoft. The drivers that Microsoft traditionally provides (most of them, really) were ready in XP64.

Yes, Vista now uses an image based install that supposed to be much faster.

2000 fully supported ACPI power modes. There have been minor refinements since then, but noting major.

SuperFetch (new in Vista) does pre-emptively fill unused memory with things that were paged out or the OS otherwise thinks you may use. To support this, the kernel now has 8 memory priorities, which help a lot in determining what should go first when memory gets tight.

XP had MCE first.

Note that per-file encryption has been supported since 2000.

There have been some redirection shims since XP at least.

Epically? It certainly takes more clicks to get into the adapter list control panel. There are automatic locations in Vista that automatically config your firewall and such, but XP works fine if you just want to connect to the network.

It's better, but there's still a lot of apps that break

XP will offer to search for drivers for unknown hardware, and include driver updates in Windows Update.

XP has prefetching and a lot less to load than Vista or "7". Why would the UI responsiveness be any better?

Windows 7 does have improvements, don't get me wrong I'll probably upgrade to it, but it's not making a major advance in every area. XP still does most of what 7 and Vista do, and using less resources. Besides, Vista was the major version change to 6.0.

Actually, there is a port of Office 97 to Alpha for NT3.51 and NT4. This site is dedicated to NT on Alpha and mentions some compat issues between running native Office and emulated x86 office.

Actually, there are two parts to a video driver on Windows NT, in all versions up to 5.2. In the "Windows 2000 Display Model" (the same one used in NT4), the vendor supplies a display driver, and a miniport driver.

The miniport handles things like resource allocation, memory mapping, handle interrupts, etc. This has always been in kernel mode, because it has to talk to the hardware.

The display driver is for high level drawing and rendering commands. It provides accelerated interfaces for GDI, DirectDraw and Direct3d. This, along with the Win32 windowing and graphics servers (left side of original diagram), used to live in user mode int NT3.x inside of csrss.exe with winsrv.dll. CSR still contains many functions that were never moved into kernel mode in win32k.sys.

Performance was one reason to move the display driver and winsrv into kernel mode, but I guess the biggest reason was to simplify the interface between the Win32 server and user mode clients by eliminating all the IPC marshaling. Win32k can now just reach into the client process's memory, same pointers and everything, instead of packing things into shared memory or an LPC messages.

Vista's new display model is more complex, but for the most part has a user mode display driver again.

It's called price discrimination. More editions help Microsoft soak up more consumer surplus.

The 6581 SID chip, which produces sound on the C64 is not programmable. The 6510 CPU has to spoon feed it commands to produce a song.

.MID files and windows metafles are a sequence of commands with parameters and (for MIDIs) timings that describe content. These commands are a high level description of the content. A generic player is capable of interpreting these instructions to render output. The C64 never had a common format like that for music. Instead, each song is a unique program for the 6510 CPU dedicated to a single song that outputs through the SID chip. Instead of describing notes directly, it has 6510 machine code instructions for loading registers, doing arithmetic, storing to memory, controlling hardware, etc. just like it was a real computer. These are usually created by excising the music portion of a larger program to make it a standalone program that just plays a song with no input. To play a song, an emulator for the 6510, 6581, memory, ROM and enough other hardware is required to let the sound program execute like it would on a real 64, controlling emulated the SID chip the same way.

This format is popular because the vast majority of original music was already in program format, and the machine code programs are much shorter than a literal description of the program's SID output.

See MOS Technology SID - Software emulation

I agree that Apple should be able to verify that full emulator is safe to execute arbitrary code that can't escape, but as other posters have noted, this may not be Apple's only concern.

That's mostly right, but I think the kernel's role is a bit smaller.

Tokens, which identify the access that a process gets, and access checks against kernel objects with security descriptors are indeed handled by the kernel. Integrity levels attached to tokens and mandatory integrity labels are new properties that the kernel allows for tokens and security descriptors and consults during an access check in Vista. That's really the extent of kernel involvement for integrity labels.

The decision of what to put into a token or security descriptor has always been up to user mode components. Winlogon uses a restricted, medium integrity version of an administrator's token for starting the shell. IE launches a low integrity child process of itself. Certain functions, like Win32's CreateProcess check the image manifest for requestedExecutionLevel and enlist the seclogon service if needed to elevate the new process. The kernel syscall to create a process doesn't do any of this.

Windows messages are implemented by the Win32 subsystem, not the kernel (even though part of Win32 does run in kernel mode in win32k.sys). The kernel does supply several IPC methods, but not this one. Win32 does the target window integrity check (UIPI).

I would say that UAC is a user mode construct, mainly implemented in winlogon, kernel32.dll, LSA and the seclogon service. The kernel does enforce restricted tokens and integrity labels for kernel objects though. I can't say that the NT security model has been followed as well as it could be (part of this is due to its complexity), but Vista (and UAC) do use a lot more of it, and seem to have avoided serious security or compatibility problems. One issue is that NT was designed for use on a LAN with trusted programs and the security system was for protecting users and the system from unauthorized users, not from malicious programs. Thus, the owner of a computer is the Administrator, since the system doesn't have anything that user shouldn't have access to. Unfortunately, this doesn't work so well when that admin can't trust all the programs on the system to behave.