Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mark Russinovich on Windows Kernel Security

ScuttleMonkey posted more than 7 years ago | from the other-side-of-the-coin dept.

181

An anonymous reader writes to mention that in the final part of his three part series, Mark Russinovich wraps up his look at changes made in the Windows Vista Kernel by exploring advancements in reliability, recovery, and security. "Applications written for Windows Vista can, with very little effort, gain automatic error recovery capabilities by using the new transactional support in NTFS and the registry with the Kernel Transaction Manager. When an application wants to make a number of related changes, it can either create a Distributed Transaction Coordinator (DTC) transaction and a KTM transaction handle, or create a KTM handle directly and associate the modifications of the files and registry keys with the transaction. If all the changes succeed, the application commits the transaction and the changes are applied, but at any time up to that point the application can roll back the transaction and the changes are then discarded."

cancel ×

181 comments

Sorry! There are no comments related to the filter you selected.

Not dupe, but almost (1, Interesting)

vivaoporto (1064484) | more than 7 years ago | (#18434685)

Although this is technically not a dupe, it is almost, as the above linked article is the Part 3 and the other submitted and discussed article [slashdot.org] was the Part 1, isn't it kinda repetitive? What now, someone post a multipart article and we will get one story here on front page for each part?

On topic now, I don't like the way Russinovich is blowing Vista's horn now. I liked him more when he was more critical and analytical on what could be improved, instead of what has already been done.

Re:Not dupe, but almost (4, Interesting)

Bonker (243350) | more than 7 years ago | (#18434741)

MS made a good move in hiring Russovitch. We can hope that he has more positive influence over kernel changes to XP and Vista than MS has bad influence over things that he does and does not get to say and software (sysinterals) he does or does not get to release.

Re:Not dupe, but almost (5, Insightful)

suv4x4 (956391) | more than 7 years ago | (#18434791)

On topic now, I don't like the way Russinovich is blowing Vista's horn now. I liked him more when he was more critical and analytical on what could be improved, instead of what has already been done.

He's working at Microsoft now, you do realize that "what could be improved" he's actually doing right now, so he can call it "already been done".

You don't really prefer pointless critique with no improvement, do you.

Re:Not dupe, but almost (1)

LordSnooty (853791) | more than 7 years ago | (#18434921)

Yeah, GP is a rather odd comment. Maybe what he said should be done has been done, and now he can talk about how it's implemented. He's a clever guy, I'm sure MS didn't employ him just so they could get their hands on Process Explorer. I guess this factoid was lost on 'first post'

Re:Not dupe, but almost (1)

vivaoporto (1064484) | more than 7 years ago | (#18434925)

He's working at Microsoft now, you do realize that "what could be improved" he's actually doing right now

You don't really prefer pointless critique with no improvement, do you.

Point conceded.

Re:Not dupe, but almost (0)

Anonymous Coward | more than 7 years ago | (#18438535)

You don't really prefer pointless critique with no improvement, do you[?]

You must be new here.

Re:Not dupe, but almost (3, Insightful)

dedazo (737510) | more than 7 years ago | (#18434991)

On topic now, I don't like the way Russinovich is blowing Vista's horn now. I liked him more when he was more critical and analytical on what could be improved, instead of what has already been done.

Fresh blood always brings fresh perspectives. Mark has been on the outside looking in for long enough that he probably has a fairly asymetrical view of the NT kernel to that of the core MS developers, and in software development (especially at that level) that tends to be extremely useful.

Re:Not dupe, but almost (4, Insightful)

EllynGeek (824747) | more than 7 years ago | (#18435937)

Sysinternals was one the very few companies with the expertise to dissect and analyze Windowses truthfully. It's no accident that after the Sony rootkit fiasco they were quietly acquired by microsoft. Just one more assimilation.

Re:Not dupe, but almost (0)

Anonymous Coward | more than 7 years ago | (#18436067)

Uhh...not to ruin your perspective here, but that's not a horn....

Presidential Memo To Slashdot: +1, Patriotic (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18434707)


Dear Slashdot Computor Geniuses:

I need to change the dates on our e-mails about firing U.S. attorneys who failed to comply with my Patriotic (tm)
orders to frame Administration critics.

Any help would be greatly appreciated pronto before I have to do a Nixon [wikipedia.org] .

Criminally yours,
George W. Bush

Message to Microsoft (2, Funny)

bonefry (979930) | more than 7 years ago | (#18434711)

Just leave my applications alone !

Re:Message to Microsoft (0)

Anonymous Coward | more than 7 years ago | (#18436269)

Message from Microsoft: "We hold all the cards, and we have the monopoly. Dance or die: we don't care."

Nahh (1)

El Lobo (994537) | more than 7 years ago | (#18434719)

Don't slashdotters say that Vista is the same than XP? Slashsuckers must be right, of course.

doesn't belong in the kernel (4, Insightful)

nanosquid (1074949) | more than 7 years ago | (#18434779)

There is little reason to put these kinds of transactional services into the kernel: they don't involve security or user permissions and they must be efficiently implementable in user code anyway (otherwise, most databases wouldn't work well on NT). So, I'd classify this as "kernel bloat".

Re:doesn't belong in the kernel (2, Insightful)

Bacon Bits (926911) | more than 7 years ago | (#18434967)

Yet PS3 portability was *absolutely vital*.

Re:doesn't belong in the kernel (0)

Anonymous Coward | more than 7 years ago | (#18435045)

Here's a tip: C has a handy feature called #ifdef. Check it out sometime.

Re:doesn't belong in the kernel (1)

Bacon Bits (926911) | more than 7 years ago | (#18435437)

#ifdef is a pre-processor instruction. It's not C code at all.

Re:doesn't belong in the kernel (0)

Anonymous Coward | more than 7 years ago | (#18435477)

Whoosh.

Re:doesn't belong in the kernel (1)

EvanED (569694) | more than 7 years ago | (#18435481)

Here's another top... the preprocessor is part of C.

Not that you should be using ifdef to separate platform-specific code anyway... it should be put into another file.

Re:doesn't belong in the kernel (1)

Bacon Bits (926911) | more than 7 years ago | (#18435649)

It's not really part of C, though. It's a common program that parses C code for errors and also listens to instructions means specifically for it. It's run as part of the compiler, but the compiler is not C either. C is a language, not a program.

It's like saying that PHP *is* HTML.

Re:doesn't belong in the kernel (1)

TheRaven64 (641858) | more than 7 years ago | (#18435749)

The ISO C specification includes the preprocessor functionality. The original K&R spec did too.

I have not seen a copy of the HTML specification that included any mention of PHP.

Re:doesn't belong in the kernel (2, Insightful)

EvanED (569694) | more than 7 years ago | (#18435759)

C is a language, not a program.

Yes, I realize that.

And the preprocessor directives are part of that language. Or perhaps you missed sections 5.1.1 and 6.10 of the description [open-std.org] of that language? (Assuming the numbering stayed the same from draft to final.)

Re:doesn't belong in the kernel (1)

Bacon Bits (926911) | more than 7 years ago | (#18436075)

Yes, I'm aware it's standardized in the ANSI spec. Nevertheless, I still don't consider it true C code. Preprocessor code is metacoding. Similarly, I don't consider !doctype to be true HTML, and so on. Metacode is extremely useful, and in the case of C it was decided that it is so useful that standardizing it was required. But metadata and metacoding is a secondary language used to facilitate the requirements of the primary language.

If you want to stomp your feet and pout, go ahead.

Still. Not. C.

OT: sig (0)

Anonymous Coward | more than 7 years ago | (#18437153)

Digg is what would happen to SlashDot if Fark invaded.

There's another theory that says that this has already happened...

Re:doesn't belong in the kernel (0)

Anonymous Coward | more than 7 years ago | (#18435555)

A truly pathetic attempt at getting the last word on the (completely accurate) previous post by being pedantic.

You prat.

Re:doesn't belong in the kernel (4, Informative)

Lally Singh (3427) | more than 7 years ago | (#18435013)

They also involve atomic I/O to multiple systems simultaneously. Userland can't do this. Databases work on one system, their own data files, and have full control over these files.

Userland apps don't have that kind of control over the registry. Hell they may not be sure to have that kind of control over the files they're manipulating.

Besides, I'd rather have this code once in a DLL than 10 times in 10 different apps. That's real bloat.

Mod up (0)

Anonymous Coward | more than 7 years ago | (#18435131)

It's what I was going to say

Re:doesn't belong in the kernel (3, Insightful)

swillden (191260) | more than 7 years ago | (#18436245)

They also involve atomic I/O to multiple systems simultaneously. Userland can't do this.

Of course it can. As long as the OS provides atomic I/O operations on individual files, the logic for implementing two-phase commit is the same in userland or in kernel space. For that matter, atomic I/O can be implemented entirely in userspace, as long as the OS provides a mechanism for userspace to find out when the data has actually been written. It's more convenient to put single-file atomic I/O in the kernel, though (or at least in the file system).

Besides, I'd rather have this code once in a DLL than 10 times in 10 different apps.

That's not an argument for putting it in the kernel.

Re:doesn't belong in the kernel (4, Informative)

dgatwood (11270) | more than 7 years ago | (#18437415)

Of course it can be done in user space. If a user space app can't do it, neither can the kernel. And it isn't atomic I/O. There's no such thing as atomic I/O. I/O operations are reordered, split, combined, etc. by everything from the OS to the controller to the hard drive, and for network volumes, it is even worse. There's no practical way to guarantee atomicity, so you have two choices: have filesystems (including remote filesystems) with rollback capabilities (which still don't completely guarantee anything) or design a file structure that achieves the same thing (which still doesn't guarantee anything). The former is nice for a lot of reasons (e.g. so that every developer doesn't have to reinvent the wheel), but isn't essential by any means. It also would greatly increase the complexity of the VFS layer and filesystems written for it, so if that is the only purpose for doing transactions, it makes a LOT more sense to implement them in a user space library instead of in the kernel.

If your sole purpose is to be able to do multi-file rollbacks, user-space transactional support is as easy as designing your file format and/or layout around it. There are two easy ways to do this: files with built-in history and using swappable directories.

Files with built-in history:

For the initial modification pass, modify each file by appending what amounts to a diff footer. If an error occurs, you can undo all of the changes by truncating the files prior to the latest diff footer. Once these modifications are complete, you no longer need to worry about rolling anything back (except for cleaning up temp files if something fails in the second pass) because the data is safely on disk. (Note: this does require that the kernel and all devices and/or network disks reliably flush data to disk upon request. Don't get me started on buggy ATA drives.)

In the second (optional) pass, you coalesce the diff into a new copy of the file and swap the compressed version in place of the original file. This is generally an atomic operation in most operating systems. If anything occurs during the second stage, it is a recoverable failure, so there is no need to roll anything back. Heck, Microsoft's file formats pretty much do this anyway. (Notice the 500 megabyte single page MS Word document that occurs when you make lots of changes and always "save" rather than "save as".)

Swappable directories

The easiest way (tm) to handle system configuration files in an atomic fashion is to modify config files in the same way you would perform a firmware update: you have an active configuration directory and an inactive configuration directory. You read the active one, make changes, and write to the inactive one. Then you trip a magic switch (tm) that says that the previously inactive directory is now active, and vice versa. Assuming you don't have out-of-order writes going on (which the kernel can't really guarantee any better than user space, sadly), this is a very easy, effective way to perform an atomic commit. And if you have an "exchange in place" operation in which the data for two files or directories in the same directory are swapped in a single atomic operation, that's a really lightweight way to implement an atomic commit/rollback mechanism without most of the complexity.

Considering how easy this is to deal with in user space, the only legitimate reason I can think of to do it in the kernel is so that you can take it out of application control entirely (e.g. to make it easier to sandbox an untrusted application). Otherwise, it makes a lot more sense to do this in a library. Now if it had snapshotting where you could roll back the entire filesystem to arbitrary points in time, that might be interesting (for different reasons)... but basic transactional support in a filesystem is much less so, IMHO, unless your purpose is to be able to sandbox an application. If so, then all this other stuff basically comes for free. In that context, doing this in the filesystem layer makes sense. However, if that is not their purpose for doing this in Vista, then kernel bloat definitely strikes me as an accurate depiction.

Just my $0.02.

Re:doesn't belong in the kernel (4, Interesting)

Anonymous Coward | more than 7 years ago | (#18435199)

Because, unlike a DB's transactional system, Vista's is fully pluggable meaning that anything can build volatile transaction management into their application or driver and automagickally gain the benefits of a single logging mechanism and full support for distributed transactions.

And yes, this is a really big deal. Other than maybe OS/400 I know of no system where file system operations can be done atomically with database operations. I can poll data, write a file and update that data all in one atomic operation. Either the data has been exported and marked as such, or not. No in-betweens. No incomplete files. No complete files despite a failure to mark the data in the database. No attempt to manually compensate for errors. It's all there, one operation, atomic and automatically so. This is absolutely massive for my world where financial and business transactions are moved constantly in such a fashion.

Yes, Microsoft does innovate sometimes. This is one of those occasions.

Re:doesn't belong in the kernel (2, Informative)

nigelo (30096) | more than 7 years ago | (#18435889)

> Yes, Microsoft does innovate sometimes. This is one of those occasions.

Well, DEC VMS had this capability decades ago, so is it really innovation?

http://h71000.www7.hp.com/commercial/decdtm/index. html [hp.com]

Re:doesn't belong in the kernel (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18437091)

Yes, it is innovation. The feature you linked to in VMS is a distributed transaction coordinator. Windows has had this component (called DTC) for years.

The actual innovation is making a Kernel Transaction Manager, along with a resource manager for the filesystem. The KTM means that transactions can be inherited from parent process to child or joined by a cooperating process. Having a transactional filesystem means that all file operations can be all-or-nothing. Power goes out during a major update? No problem, because when you boot up again the filesystem will be recovered and it will be like the update was never started. And the beauty of having the resource manager in the filesystem is that you can combine the filesystem transactions with any other ones in the system (via the DTC). In fact, they could even make it so that you can combine transactions across systems so that moving files from one server to another would be atomic.

dom

Re:doesn't belong in the kernel (0)

Anonymous Coward | more than 7 years ago | (#18438645)

Other than maybe OS/400 I know of no system where file system operations can be done atomically with database operations ... Yes, Microsoft does innovate sometimes. This is one of those occasions.

Ummm, you say this features exists in OS/400, so it's hardly innovation. Mass-marketing, maybe.

Mod Parent (Farther) Up (1)

jthill (303417) | more than 7 years ago | (#18438933)

This is cross-facility transaction management: registry and filesystem updates combined into a single transaction. The example in TFA that an entire install can be atomic: multiple filesystems, registry, everything appears complete and as requested, all at once, or it never happened.

It's extensible, if TFA is to be believed at all, and the facility works. It's actually there and in use, rather than an it'll be there someday and won't it be wizzo promise, so I'm in "trust-but-verify" mode. It'll be interesting to see if it's actually extensible by coders excluded from the Blessed Realm.

Whether it belongs in the kernel or not is all but irrelevant: so what if it could be implemented as a userland service? Where they choose to put their code is up to them. They wanna play micro-kernel, Giga-kernel, or kernel-a-la-carte, that's up to them; the only question is whether the result is as reliable as they want us to believe.

If it is, it will make building absolutely-bulletproof applications a whole hell of a lot easier. I know something about that. Being able to say ~`if (!quickcheck()) die(fromhere());`~ without leaving a mess means, just for starters, that you don't have to concoct a file format for complex data; you can just use the filesystem, and that choice won't complicate your life. Big win. Big.

Re:doesn't belong in the kernel (0)

Anonymous Coward | more than 7 years ago | (#18435253)

I would hardly concider transactional file systems not worth the effort - from what I understand NTFS journal already makes various operations atomic. The vista improvements just allow you to group a series of changes using a explicit transaction concept.

Database servers in effect implement their own storage primitives within single files on the operating systems file store and have nothing to do with this issue.

If the kernel file system driver does not provide primitives to control transaction functions the result is the kludge of temporary files/locking approaches with all of the classic issues developers have been facing with these approaches for years.

Its very similiar to the reason online defragmentation of disk drives require OS primitives to control. Sure applications or libraries can try and reserve contiguous spaces on disk but it is more effective and more benefical that it be done at a lower layer where applications are allowed to be ignorant of what is happening.

Re:doesn't belong in the kernel (1, Informative)

Anonymous Coward | more than 7 years ago | (#18435337)

The majority of the framework is implemented in userland. See the Distributed Transaction Coordinator service.

Re:doesn't belong in the kernel (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18435345)

Think outside your small box. These features can provide significantly more than current user-mode transaction management that databases (or OLTP monitors) provide today.

For instance, how does a user-mode controlled file-system transactions rollback changes on reboot? Consider what happens when the change involves system files. NTFS handles this cleanly in Vista but any attempt to do this with a user-mode service would fail because the system files would already be in-use by the time the service started. Further, any transactions in-doubt would remain in-doubt until the service started (if you could get that far).

Similarly, what about settings in the registry? Consider if the transaction spanned installing a driver and updating its settings. What happens if the system powers down midway through that update? Without kernel-level transactions that are available at boot-time you cannot easily recover before inconsistent settings are used with the driver.

Beyond the boot-level support; another exciting aspect about the KTM is that this is a transaction-manager that provides transactions that can be shared across multiple processes. Try that with a user-mode transaction manager like XA or DTC and see your per transaction performance. By managing the transaction in the kernel, the 2PC performance is significantly improved.

In the end, NTFS and the registry live in the kernel -- so their tramsaction manager also has to live in the kernel. That is just the way it works.

Another exciting aspect covered is the ability to coordinate DTC transactions with KTM transactions. Meaning, you can coordinate your SQL Server (or Oracle) updates with your file-system updates. This is cool! No longer do you have to worry about finding orphan-files in workflow applications or other applications that manage both files and relational data.

Lastly, they are talking about full ACID properties with NTFS's transactions. Think about it -- you could update every file on your web server, in place, while its wild with activity. All your changes are isolated from the users until you say "commit" in your application.

Re:doesn't belong in the kernel (0)

Anonymous Coward | more than 7 years ago | (#18438877)

For instance, how does a user-mode controlled file-system transactions rollback changes on reboot?

When the file is first opened, the library code rolls it back if necessary.

Consider what happens when the change involves system files. NTFS handles this cleanly in Vista but any attempt to do this with a user-mode service would fail because the system files would already be in-use by the time the service started.

When the file is first opened, the library code rolls it back if necessary.

Similarly, what about settings in the registry? Consider if the transaction spanned installing a driver and updating its settings. What happens if the system powers down midway through that update? Without kernel-level transactions that are available at boot-time you cannot easily recover before inconsistent settings are used with the driver.

With that approach to design, it's no wonder Windows wedges so much: there are many ways in which settings and drivers can become inconsistent, so relying on transactioned updates to prevent that from happening is unreliable.

Beyond the boot-level support; another exciting aspect about the KTM is that this is a transaction-manager that provides transactions that can be shared across multiple processes. Try that with a user-mode transaction manager like XA or DTC and see your per transaction performance. By managing the transaction in the kernel, the 2PC performance is significantly improved.

Well, that may be true for Windows, since Windows appears to have trouble with the performance of user-mode services, but on UNIX, I'd expect a user mode implementation to be faster, not slower, than a kernel mode implementation.

In the end, NTFS and the registry live in the kernel -- so their tramsaction manager also has to live in the kernel. That is just the way it works.

Well, one bad design decision drives another.

Another exciting aspect covered is the ability to coordinate DTC transactions with KTM transactions. Meaning, you can coordinate your SQL Server (or Oracle) updates with your file-system updates. This is cool! No longer do you have to worry about finding orphan-files in workflow applications or other applications that manage both files and relational data.

If this is a problem for MS SQL Server, then it is poorly designed; UNIX RDBMs do not have this problem.

Lastly, they are talking about full ACID properties with NTFS's transactions. Think about it -- you could update every file on your web server, in place, while its wild with activity. All your changes are isolated from the users until you say "commit" in your application.

I can do that already, without NTFS, or a transaction manager, or any form of kernel level transactions.

Well, mainly what your comments illustrate is that on Windows, one bad design decision drives another.

Re:doesn't belong in the kernel (0, Troll)

ChrisA90278 (905188) | more than 7 years ago | (#18436559)

NO. it DOES belong in the kernel. The reason is because these changes must appear to be atomic to other processes. Can't do this in user space

Re:doesn't belong in the kernel (1)

nanosquid (1074949) | more than 7 years ago | (#18438441)

Of course, you can do it in user space. You could do that in user space already in UNIX V7, and it's been used for anything from atomic system upgrades to maintaining gigabyte mail spool directories without data loss (something that Exchange doesn't seem to be able to achieve to this day). You really don't need a transaction manager in the kernel for that; any one of a number of existing kernel operations is sufficient.

Re:doesn't belong in the kernel (0)

Anonymous Coward | more than 7 years ago | (#18436749)

this is why i love reading slashdot... the very first reply to this article is, "why is this in userland?" the second replay is, "why is this in the kernel?"

you correctly realize that not every api should be implemented in the kernel, but incorrectly believe that every api is. another posters correctly realizes that this api is not implmented in the kernel, but incorrectly believes that every api should be.

and you're both the highest modded posts in the whole damned thread.

learn from biology (0, Redundant)

wizardforce (1005805) | more than 7 years ago | (#18434875)

I wonder if these new "security features" put into Vista no matter how good they at first appear to be, will over time be bypassed, comprimised and made obsolete. The main problem is that security only goes as far as the person using the OS lets it. just look at the UAC- it's annoying, and many people disregard it or shut it off entirely. what now is the security benefit? These features only make VIsta "more secure" because they have not yet been exposed to the wild for sufficient time to be comprimised as thoroughly as prior versions. It is much like in biological systems, for example penicillin was not widely utilized in fungal kindoms and it was thus effective as an antibiotic- once we spread its interactions with bacteria, bacteria developed a resistance. Vista is no different- only this time security threats are the bacteria and Vista is the antibiotic.

Kernel enhancements? Are you sure? (2, Insightful)

Applekid (993327) | more than 7 years ago | (#18434935)

According to the bottom of just one function of the KTM reference [microsoft.com] :

"Requires Ktmw32.dll."

Why would a kernel add-on require a .dll, exactly? Did I miss some Windows fundamental about it's kernel? And if it's not really a result of a kernel enhancement, is this yet another potentially useful technology specificly excluded from earlier versions of Windows entirely for business purposes instead of technological limitations?

What is the registry in Vista? (2, Interesting)

mosel-saar-ruwer (732341) | more than 7 years ago | (#18434957)


For years, the "Registry" was some weird mish-mash of binary files, many of which represented Jet databases.

Has Jet been completed abandoned in Vista?

If so, did they switch to the slimmed down SQLServer [that was supposed to be part of WinFS]?

Re:What is the registry in Vista? (1)

allanw (842185) | more than 7 years ago | (#18435127)

Nope, the registry is still a bunch of binary files, located in the same folder.

Re:What is the registry in Vista? (5, Informative)

Foolhardy (664051) | more than 7 years ago | (#18439447)

The registry is a single root hierarchical database with registry hive files mounted at the second level (below \REGISTRY\MACHINE and \REGISTRY\USER for the computer's config and user config, respectively). The registry engine is implemented in kernel mode as an executive subsystem (inside ntoskrnl.exe), where it is known as the Configuration Manager. Registry hives use a transaction journal (like many filesystems do) to avoid corruption during a power failure or crash. Standard system hives are located in %SYSTEMROOT%\System32\Config and include SAM for local user accounts, SECURITY for various secrets held by the computer, SYSTEM for core system configuration early during boot, and SOFTWARE that stores all other config associated with the computer in the registry. Every user profile has its own registry hive for user-specific configuration. Everything above is still the same in Vista as it was in NT 3.1.

There are two database engines that have been known as Microsoft "Jet", known as Jet Red and Jet Blue. Jet Red [wikipedia.org] is also known as the Access database engine. It is a fairly featureful SQL database. Jet Blue is now officially the Extensible Storage Engine [wikipedia.org] (ESE), and has been a system component since Windows 2000, backing WMI data, Active Directory, Exchange, and others. It is an ISAM database and is optimized for large sparse tables and also supports a transaction journal. Both are 100% user-mode and were not a part of the initial release of Windows NT. Microsoft has said that Jet Red is depreciated, and that future versions of the Access database engine will be integrated with Access and not have a public interface. Jet Blue's interface is well documented [microsoft.com] and will continue to see use for some time to come. Both being user-mode, dependent on Win32 and the wrong type of database (relational vs hierarchical), the Jet engines would not be suitable replacements for the registry.

SQL Server is a high-end SQL database engine. It was rumored that WinFS would use SQL Server Express and that Microsoft eventually plans to move some of the services that use Jet Blue to SQL Server (such as Active Directory). In any case, SQL Server is an even less possible replacement for the registry.

Microsoft has not gotten rid of the Registry in Vista. In fact, the new boot manager uses a registry hive to store boot configuration, replacing the old boot.ini.

Re:Kernel enhancements? Are you sure? (4, Informative)

Cyberax (705495) | more than 7 years ago | (#18435139)

Because this DLL is just an interface to kernel features.

Windows NT was initially designed to use single kernel for different subsytems (OS/2 subsystem, POSIX subsystems, etc.). Subsystems are implemented as dynamic modules talking with the kernel through LPC (Local Procedure Call, see http://en.wikipedia.org/wiki/Local_Procedure_Call [wikipedia.org] ). So in this case ktmw32.dll just wraps LPC calls in a nice API. That's actually a rather good design.

Re:Kernel enhancements? Are you sure? (4, Informative)

EvanED (569694) | more than 7 years ago | (#18435229)

Windows NT was initially designed to use single kernel for different subsytems (OS/2 subsystem, POSIX subsystems, etc.)

Not just initially designed, it DOES use a single kernel for different subsystems. You can't get the OS/2 one any more, but the POSIX subsystem morphed into (part of) the Services for Unix which has become the Subsystem for Unix-based applications.

On 32-bit Windows, 16-bit Windows applications are handled by the "Windows on Windows" subsystem. On 64-bit Windows, 32-bit Windows applications are also handled by a "Windows on Windows" subsystem, though a different one than WOW16.

Re:Kernel enhancements? Are you sure? (0)

Anonymous Coward | more than 7 years ago | (#18435153)

Um, so that you can access it from userland? How the heck do you expect applications to be able to use it?

Re:Kernel enhancements? Are you sure? (1)

Keeper (56691) | more than 7 years ago | (#18435195)

The dll performs the mapping from the "nice" function call you see in MSDN to the system call(s) required to perform the desired operation.

Re:Kernel enhancements? Are you sure? (1)

anImortal (317717) | more than 7 years ago | (#18435411)

Its a small DLL that provides you with Win32 APIs to call kernel (Nt) functions.

Hmmm... Upgrade to Ultimate Vista perhaps? (3, Funny)

pegr (46683) | more than 7 years ago | (#18435061)

"If all the changes succeed, the application commits the transaction and the changes are applied, but at any time up to that point the application can roll back the transaction and the changes are then discarded."
 
What, was my credit card declined for my upgrade to Vista Ultimate Edition?

Re:Hmmm... Upgrade to Ultimate Vista perhaps? (1)

anImortal (317717) | more than 7 years ago | (#18435639)

Just like any database -- from any vendor. If you start running out of system resources, your transaction will likely roll-back.

Not exactly "error recovery" (5, Insightful)

Ancient_Hacker (751168) | more than 7 years ago | (#18435239)

Recovery? The Windows Registry is the exact opposite of recoverable:

  • "Regedit" has no Undo command. It applies changes immediately.
  • The Registry file is in a proprietary and undocumented format.
  • One scrozzled byte in the Registry can make it completely broken and make the system unbootable.

Not exactly most people's idea of robust and recoverable.

Re:Not exactly "error recovery" (0)

Anonymous Coward | more than 7 years ago | (#18435581)

Possibly because you're not supposed to fuck with it!. MS rarely suggest you tinker in the registry and when they do they tell you to be damn careful, there are confirmation prompts before you delete keys as well. This is like complaining about rm borking your box because you pressed f instead of d or whatever.

Re:Not exactly "error recovery" (5, Insightful)

bmajik (96670) | more than 7 years ago | (#18435653)

The registry can be backed up and restored, in whole or in subsections.

The format of the registry is largely irrelevant, but it is described to some extent in the "Inside Windows xxx" series of books (which Russinovich co-authored)

Which specific byte would you "scrozzle" in the registry to render a machine unbootable? How and why would you do it?

Extra credit:
Which files under /boot, /etc, /sbin, and so on would you be willing to stake your career on being "safe to corrupt by 1 byte" and still guarantee a bootable system?

There are things to like or dislike about either a registry based approach (opaque data storage with a defined interface) vs a flat text based approach (clear data storage with an undefined interface). I don't think you make a compelling "anti-registry" argument with the points you list, however.

Re:Not exactly "error recovery" (2, Insightful)

fabs64 (657132) | more than 7 years ago | (#18436197)

Difference being you're not supposed to modify things in /boot and /sbin for all your settings, and /etc is text and therefore much harder to screw up. (you could put an EOF as the first byte in the file, but the system will still probably at least give you a "file x is empty" error message).

What you've said is correct, the gp's gripe is really about using a binary configuration file.. a fairly stupid decision but that is only my opinion.

My argument for flat text (or xml or whatever) over binary, is the same as every argument about the two for the past 5 years, binary is too system specific, reading/writing it is almost always more painful (faster though), reverse-engineering the format is always a much bigger job.

The "defined interfaces" argument doesn't really wash, you can define an interface just as easily for a text file as you can for binary, however with text someone may be able to edit it by hand or write their own interface, with binary this is much more difficult.

I think what it really comes down to is this; If you decided to write a new OS today from scratch and wanted to have a central configuration database (a good idea, as shown by /etc), would YOU come up with the windows registry?

Re:Not exactly "error recovery" (1)

CliffSpradlin (243679) | more than 7 years ago | (#18437503)

Just to be clear, there are some standard unix programs that store binary configuration information in /etc, such as tripwire. Either way, you can quite definitely completely fuck up your system by editing the wrong files in /etc. /etc is NOT a central configuration database by any means, and it certainly is not one with a standardized interface. This is not to say that the registry is any better or worse. (Note, I hate the registry, but it's largely in part due to the below reason)

What it comes down to is it's not the configuration system provided at fault as much as how the system is used by applications and system libraries. Any configuration paradigm can be abused.

Re:Not exactly "error recovery" (1)

fabs64 (657132) | more than 7 years ago | (#18437677)

How is the interface to /etc not standard..? Last I checked we have the navigation of filesystems pretty down-pat.
Obviously what an app puts into its configuration files is undefined, but I'm pretty sure you can put Strings in the registry as well?
The registry is essentially a (bad) re-implementation of a filesystem, it's no more standardised (less so really) than just USING the filesystem.

Re:Not exactly "error recovery" (2, Insightful)

bmajik (96670) | more than 7 years ago | (#18438697)

Are you seriously asking?

what is the comment convention?
What is the whitespace convention?
Does this version of this flavor use spaces or tabs in /etc/fstab (or is it /etc/vfstab on today's OS?)
What are the file locking semantics?
Which set(s) of files are logically related to the same peice of functionality?
What character encodings are supported?
What _line termination_ is supported?

nfs export your /etc directory r/w some time. Let someone edit your /etc/fstab in TextEdit on a Mac. Make sure they cut-and-paste from a sample they saw on a website, or that they got via an email. Are you willing to bet your uptime on that working correctly? Even if you control the email or webpage they're pasting from.. are you _sure_ it would work? That there'd be no conversion problems?

Have you ever done a *nix upgrade on a machine? What happens to most of the files in /etc? The answer is NOT "your changes are seamlessly rolled forward"

Re:Not exactly "error recovery" (3, Insightful)

drsmithy (35869) | more than 7 years ago | (#18437577)

Difference being you're not supposed to modify things in /boot and /sbin for all your settings, and /etc is text and therefore much harder to screw up. (you could put an EOF as the first byte in the file, but the system will still probably at least give you a "file x is empty" error message).

Users aren't supposed to modify the Registry, either.

What you've said is correct, the gp's gripe is really about using a binary configuration file.. a fairly stupid decision but that is only my opinion.

It was designed in the late '80s (well, arguably the late '70s) when a 20Mhz 386 with 4MB of RAM was "bleeding edge". Text-parsing is expensive.

I think what it really comes down to is this; If you decided to write a new OS today from scratch and wanted to have a central configuration database (a good idea, as shown by /etc), would YOU come up with the windows registry?

Windows NT wasn't designed today, it was designed in the late 80s.

Re:Not exactly "error recovery" (1)

fabs64 (657132) | more than 7 years ago | (#18437707)

So about when did /etc become the de-facto standard in Unix for configuation?
"It was designed a long time ago" is not a valid argument for how something is today.
"Users" aren't supposed to modify the registry, but it's still where apps store settings, what app is storing settings in /sbin or /boot?

Re:Not exactly "error recovery" (1)

drsmithy (35869) | more than 7 years ago | (#18437943)

So about when did /etc become the de-facto standard in Unix for configuation?

No idea, but since /etc and the Registry are worlds apart in function, purpose, usage and capabilities, it's hardly relevant.

"It was designed a long time ago" is not a valid argument for how something is today.

It most certainly is. You can't just remake something as big as a modern operating system from the ground up every time the latest cool fad comes around.

(And I'm sure you'd be happy to defend the train wreck that is /etc with some line about how long it's been around, so that's just the way it is.)

"Users" aren't supposed to modify the registry, but it's still where apps store settings, what app is storing settings in /sbin or /boot?

How is it relevant ? The complaint was that twiddling the right bit in the Registry could render the whole system unbootable. The point is that the same thing can happen on any system.

Re:Not exactly "error recovery" (1)

ScrewMaster (602015) | more than 7 years ago | (#18438527)

How is it relevant ? The complaint was that twiddling the right bit in the Registry could render the whole system unbootable. The point is that the same thing can happen on any system.

Not to dispute your conclusion, but one relevant aspect is that it seems to happen one hell of a lot more often in registry-based systems. For example, my development system at work is XP-based, and for no apparent reason my Recycle Bin disappeared. Off the desktop, My Computer, just gone. No idea where it went. I first tried Microsoft's "Recycle Bin Recovery" procedure to re-enter the appropriate keys: no dice, the corruption was deeper. Fortunately found a registry tweaks site that had a reg file that restored all the required keys. I was lucky that time, other times I've been less so.

As a developer, I do use the registry for storing some settings, but only non-critical ones. I don't like the idea of putting my customer's configuration data (and in the software I work on, there's a lot of it) into the registry. Too risky, and there's no easy way for a customer to back anything up. Personally, I've never really seen the light when it comes to application data storage using the registry. I've been burned too many times.

Re:Not exactly "error recovery" (1)

newt0311 (973957) | more than 7 years ago | (#18437887)

I am being picky here but oh well. Most UNIX systems and at least Linux if nothing else have gotten rid of the EOF character in favor of just recording the file size seperately. Tossing a ^D or multiple ^Ds in a file doesn't have an effect on reading it though the parser used may make a difference.

Re:Not exactly "error recovery" (0)

Anonymous Coward | more than 7 years ago | (#18439155)

if you're going to be picky, try being correct first. EOF isn't a character, it's the physical end of the file. There are a handful of toy computer OSes from the late 70s/early 80s which used an EOF character to mark the end of the file (they only kept track of the number of blocks in the file). Unix (minix, linux, bsd, etc) have never operated that way.

Re:Not exactly "error recovery" (2, Interesting)

Talchas (954795) | more than 7 years ago | (#18436293)

/boot - kernels/initrds I'm not using (which should be tossed out). configs. I don't know what would happen if an insignificant byte in grub.conf changed, but I generally wouldn't bet on being safe. /sbin - oddly enough, lots. fdisk/cfdisk. fsck + friends would probably boot somewhat. e2image, e2label, ctrlaltdel,shutdown,mkfs*,installkernel. /etc - much of it, just to boot. Boot and have everything work, far less of it - but at least I could usually boot and I would usually know what was broken.

But yes, I understand your point. However - a broken byte in an unbacked up (yeah a bad idea) registry that causes complete failure is far far harder to find than one in /etc, as the one in /etc would generally be in a single plain-text file, and you'd often be able to guess which file from error messages. /sbin and /boot are binary files that don't contain custom configuration data - if something breaks, you can easily replace it without thinking hard. If you lost all of /etc or the registry, you would have to reconfigure your system, which may be far more work.

Re:Not exactly "error recovery" (2, Informative)

drsmithy (35869) | more than 7 years ago | (#18437767)

However - a broken byte in an unbacked up (yeah a bad idea) registry [...]

The Registry is automatically backed up at the completion of a successful system boot. This has been true since at least Windows 2000, and probably longer.

Re:Not exactly "error recovery" (0)

Anonymous Coward | more than 7 years ago | (#18437299)

Mac Users love to bash the "registry". It's like the way they used to fo complaining about "Thegmented Architectures" (with a mincing lisp) until Apple started to use Intel. (As if these mac freaks with the purple hair and eyebrow rings even need to know anything about the CPU inside their box as long as their apps run fast enough.) Apple enourages propagandists to make postings like that because its the only way they can get any sort of advantage. Their 32-year-old Unix with a little NextStep and OS-9 slapped on top of it is not gaining any market share. iPods are keeping the company afloat.

Re:Not exactly "error recovery" (1)

manastungare (596862) | more than 7 years ago | (#18437689)

either a registry based approach (opaque data storage with a defined interface) vs a flat text based approach (clear data storage with an undefined interface).

The GP's point was not entirely about automatic recovery from a broken structure; it was about human-led recovery. In a binary dump, even with defined interfaces, a single byte can render the entire structure non-human-readable. With a plain text file, a human can look at it and try to diagnose the problem -- simply by looking.

Re:Not exactly "error recovery" (1)

bmajik (96670) | more than 7 years ago | (#18438579)

There's no file to look at. The computer didn't boot.

If you've booted the computer off of some other media and are attempting to repair the configuration info, you're using a special tool to do it (like a text editor for /etc files, or a registry editor for the registry)

Also, I've not seen evidence that a single byte defect renders the registry unreadable or the computer unbootable. I don't dispute that this is possible, but I'd be curious to know if this is a practical issue or a theoretical complaint. For instance, there is redundancy in the registry (last known good being a different spot than current control set, for example).

Re:Not exactly "error recovery" (0)

Anonymous Coward | more than 7 years ago | (#18438767)

On Vista, if it got the portion of the registry that stores which OSes are installed, it is simply not booting. (e.g. one byte change renamed that key).

Re:Not exactly "error recovery" (1)

bmajik (96670) | more than 7 years ago | (#18439495)

Care to explain that? The "list of OSes" information that i think you're talking about is in the BCD store, which i dont think is part of the Vista registry. You muck with that via bcdedit, and the bcdstore is specifiable as an argument.

Re:Not exactly "error recovery" (1)

DeifieD (725831) | more than 7 years ago | (#18435747)

It does have an undo command, just not Edit - Undo. Welcome to a post Windows95 world.

If you screwed up the registry you could always make them bootable again, you just had to screw around at the command line. Linux does not make leaps and bounds over this fix. X not booting? Time to go screw around at the command line again.

Re:Not exactly "error recovery" (2, Informative)

Doctor Crumb (737936) | more than 7 years ago | (#18436177)

You are confusing a windowing system (X11) with an OS (Linux). While you may have to "screw around on the command line" to get X working again, everything else will continue to work just fine (filesystem, webserver, internet, etc), all of which you can use either from a virtual console or a remote connection. If explorer.exe won't start, how exactly do you fix that without sitting down with a recovery CD?

Re:Not exactly "error recovery" (0)

Anonymous Coward | more than 7 years ago | (#18436605)

Explorer.exe doesn't run until you login. If it won't start, you can always run remote diagnostics and fix it over the network. If your server has that problem, you might never notice. As a matter of fact, Longhorn Core server doesn't even come with Explorer.

The GP's point stands. The registry is no more vulnerable than any number of Unix config files. An extra newline in /etc/password will cause the same problem.

dom

Re:Not exactly "error recovery" (1)

EvanED (569694) | more than 7 years ago | (#18436665)

The registry is no more vulnerable than any number of Unix config files. An extra newline in /etc/password will cause the same problem.

Even if you accept that, it's still easier to diagnose and recover from the extra newline.

Re:Not exactly "error recovery" (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18435755)

I am surprised that no one mentioned the registry should be a CVS revisioning system. Being able to roll back/audit and have full control on what gets to read/write registry should help on security.

Re:Not exactly "error recovery" (2, Interesting)

Beryllium Sphere(tm) (193358) | more than 7 years ago | (#18436861)

I've been known to put my /etc into cvs.

Re:Not exactly "error recovery" (2, Funny)

larry bagina (561269) | more than 7 years ago | (#18439181)

I've been known to put my /penis into vagina.

Re:Not exactly "error recovery" (0)

Anonymous Coward | more than 7 years ago | (#18435801)

One scrozzled byte in the Registry can make it completely broken and make the system unbootable.
What is that magic, dangerous byte? If it ever existed, wouldn't be trivially easy to write a virus and scrozzle it? Where are these viruses?

Re:Not exactly "error recovery" (1)

Zwaxy (447665) | more than 7 years ago | (#18436235)

Viruses which immediately kill their hosts don't survive very long. Modern viruses mostly want cause as little disruption to their host as possible in order to avoid detection while they carry out their owner's bidding.

Re:Not exactly "error recovery" (3, Insightful)

Penguinisto (415985) | more than 7 years ago | (#18436279)

What is that magic, dangerous byte? If it ever existed, wouldn't be trivially easy to write a virus and scrozzle it? Where are these viruses?

You can't pump V1@grA spam or DDoS packets out of a dead machine, and malware writers are definitely in it for the cash nowadays. (IIRC, a large percentage of malware specifically hides in the registry...)

/P

'Protected Processes' and PC games (4, Insightful)

JanusFury (452699) | more than 7 years ago | (#18435279)

A fairly common trend these days in PC games (mostly multiplayer ones) is the use of a kernel-mode windows driver (effectively a rootkit in most cases) to 'protect' the game from hacking. Many eastern (korean, taiwanese, etc.) game development companies opt to use this mechanism to secure their games instead of writing secure client and server code - for example, GunBound, Maple Story, Ragnarok Online, Rakion, etc... pretty much any MMO you see an ad for these days that isn't from a US or European studio uses this stuff for security. The basic mechanism it uses is that it hooks all the low level operations you can do on your system (file access, process access, etc.) and prevents you from touching anything related to the game. The end result is that you can't even so much as end-task a misbehaving game 'protected' by this driver.

With the huge amount of popularity this approach seems to have (I personally suspect it's a result of some very, very aggressive marketing on the part of the driver's developers), I wouldn't be suprised to see many games start demanding that users run them on Windows Vista, so that the 'protected process' mechanism can be used to fully 'protect' the games from users' interference. While you'd at least be able to end-task them, I can't say I see this as an improvement. It's saddening that many companies believe the solution to security is a series of hacks, workarounds, and black boxes - the only real solution is careful, methodical design and engineering. It seems very likely to me that within a few years, many PC games will refuse to run on anything except a Vista system with nothing but signed drivers loaded, and that's saddening. I dislike the notion that I am denied even basic rights to investigate what an application is doing on my machine simply for the sake of 'security', when it's trivial to set up a second machine to inspect and modify a game's network packets and cheat all I want.

Re:'Protected Processes' and PC games (3, Insightful)

mpapet (761907) | more than 7 years ago | (#18435551)

the solution to security is a series of hacks, workarounds, and black boxes

Outside of some very specific gov't spooks contract work, no one is willing to adopt the other because it's more expensive and requires more thought and risk than the average PHB can handle.

Case in point: The number of cashless casino gaming systems that are centrally managed. The average casino manager understands their casino systems are a single, massive, point of failure. Just wait till they go to cashless floors and someone engineers a jackpot for themselves.

Security programming is hard. Really hard. The developers at these companies may _want_ to do the right thing, but they don't because of the complexity and limited resources.

The big-digital-bank-robbery just hasn't happened yet.

Re:'Protected Processes' and PC games (1)

nuzak (959558) | more than 7 years ago | (#18435983)

> Just wait till they go to cashless floors and someone engineers a jackpot for themselves.

That would be a neat trick to do with the end-user UI of a slot machine. Physical security is a pretty important first step.

> The big-digital-bank-robbery just hasn't happened yet.

Actually, when you look at identity theft and fraud, you can see it's happening every single day. Think breadth and not depth.

Re:'Protected Processes' and PC games (3, Interesting)

admactanium (670209) | more than 7 years ago | (#18436631)

> Just wait till they go to cashless floors and someone engineers a jackpot for themselves. That would be a neat trick to do with the end-user UI of a slot machine. Physical security is a pretty important first step.
unless i'm misunderstanding you, slot machines already work this way. you can play a slot machine with cash, or you can use a bar-coded receipt from other slot machines. i've sat down and played a few slot machines with no cash and, even after winning some money, stood up and walked away with my winnings without any additional cash. at some point i did have to put cash into the system (the first slot machine) but you can interact with slot machines, execute transactions (plays) and be paid all without cash.

Re:'Protected Processes' and PC games (1)

mpapet (761907) | more than 7 years ago | (#18436795)

It's clearly not going to happen on the floor in front of a slot machine.

The backend running those games is on a network.

What are the chances they've got a gateway that goes to the interweb?

What are the chances they are relying on Windows for their security?

The people running the casino are pretty busy with their day-to-day stuff, not infosec.

Re:'Protected Processes' and PC games (1, Informative)

Anonymous Coward | more than 7 years ago | (#18439021)

The basic mechanism it uses is that it hooks all the low level operations you can do on your system (file access, process access, etc.) and prevents you from touching anything related to the game. The end result is that you can't even so much as end-task a misbehaving game 'protected' by this driver.

This is not true, and it's also not what a rootkit is. These games use rootkits to hide files and drivers from the Windows API, which you can do yourself just by creating a share that starts with '$' or a registry key with a NULL in it. The game is not monitoring your every action, it is simply hiding itself from your interference (and potential reverse engineering).

It goes around and comes around though - the most commonly installed rootkit is Daemon Tools, which uses rootkits to hide from games. :-)

Russinovich knows his stuff (0, Flamebait)

StarKruzr (74642) | more than 7 years ago | (#18435701)

But I wonder how long it will be before "APK" aka "AlecStaar" comes out of his rathole to talk about how Mark is a witless academic who can't possibly know more than he does, since he's the author of ZDNet-approved APKTools 2007+++++++ 99.8.10101022 SR6.

I've seen that before... (1)

harry666t (1062422) | more than 7 years ago | (#18435831)

...Somewhere... ...Yeah, I know where!

So, they reinvented the wheel once again? It seems to be: every database more complex than a flat file processed by a pair of simple perl scripts has support for transactions like this. So they invented nothing, just applied an old patch to new code.

Re:I've seen that before... (2, Insightful)

EvanED (569694) | more than 7 years ago | (#18435977)

It seems to be: every database more complex than a flat file processed by a pair of simple perl scripts has support for transactions like this.

Yes, DBs do. But traditionally file systems don't. The only other system that provides this that I know of that isn't a full-fledged database is VMS.

i will explain what he is saying... (1)

DeadDarwin (1050498) | more than 7 years ago | (#18436227)

when the NTFS files access the GHY it extends a random signal to the DFT which emulates the chip switch Architecture (CSA). Hard drives can be extruded and raised to the eye level, the apt facing the sun and look for errors at the kernel module. Then the stubs in the IIOP cloud extends its virginity toward the distributed computing components. thats how the Eifel tower was made. Hope I cleared your doubts.

Sysinternals Utilities (4, Informative)

NearlyHeadless (110901) | more than 7 years ago | (#18437009)

I just noticed today that Russinovich's utilities are available in a single-file download: http://www.microsoft.com/technet/sysinternals/Util ities/SysinternalsSuite.mspx [microsoft.com]

Re:Sysinternals Utilities (1)

PetoskeyGuy (648788) | more than 7 years ago | (#18437427)

I have a spider of sysinternals.com and all file downloads in a 24MB Zip file from the day it was announced Mark was hired by Microsoft. Not sure if anyone is interested in it. I don't have any where to host the files but I can try to email them to someone via Gmail if anyone can host it or wants a copy.

Re:Sysinternals Utilities (1)

user24 (854467) | more than 7 years ago | (#18437705)

you won't be able to gmail exe files, even inside a zip unless you rename the extension.

slap it on mytempdir.com or rapidshare.de and then anyone can grab it.

Re:Sysinternals Utilities (0)

Anonymous Coward | more than 7 years ago | (#18438947)

Or do what I do: pass whatever archive file through bzip2.exe: gmail doesn't look inside that.

Re:Sysinternals Utilities (0)

Anonymous Coward | more than 7 years ago | (#18439167)

Thanks. That's a fantastic heads up. Nigger.

Hmm (1)

mixxu (1076713) | more than 7 years ago | (#18437337)

I believe there is a bug in the tagging system. I see "security" next to "windows".

This is... (5, Funny)

Organic Brain Damage (863655) | more than 7 years ago | (#18439041)

Windows Kernel. This is Windows Kernel on ACID. Any questions?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>