Of course it's NT. How many total rewrites do you see of something this big, that also would break the code of every hardware vendor and his dog if you changed it completely?
Some interesting things done in Vista are file system transactions (possibly making a complete program install atomic, if you want to) and much better cancelling of (a)synchronous I/O. The latter part is hugely interesting, as, in my experience, an application that won't get killed is generally caused by it being stuck on an I/O syscall in the kernel. It isn't mentioned in this video for some reason, maybe because it doesn't matter to the overall kernel design; only to the I/O subsystem. Compared to some designs, the NT kernel is after all only monolithic in the sense that there is a lot of stuff running in ring 0, it's both modularized in design and linking (you don't compile a device driver into the kernel, you just load it in kernel space, that difference is actually huge).
I, for one, often talk about "XX machines", with XX being the OS used. In many situations, it's more relevant what software a machine is running, than the specific software config. Sometimes, even instruction set may be of less importance. Heck, by talking about a rack of "Apache servers", I just state that in the current discussion, what's interesting and relevant about the servers is the fact that they are running a HTTP daemon named Apache and that language is a human beast taking shortcuts over the obvious.
I think we should be thankful that mainstream media is getting accurate enough to mention that it's directly related to Windows. I can't blame them for using a description of the systems affected that I know that a lot of/.ers would use. (Except for the possible tendency to write "W1nd0wz b0x3z", in some cases.)
You can't initialize GDI without it dragging user32 into the process with it, so that's fine. It might be possible to call the Escape function in Win32K directly, but I don't see what good it will do, as it will only bring you back to your own address space. AFAIK, this is not a matter of privilege escalation. If you already have an EXE on the user machine, the exploit is useless.
A static GDI32 patch would create more problems than this patch already might do in the area of localization and different subversions, as not everyone is using US English x86 WinXP with SP2 and every available hotfix. (On the contrary, there are even non-security hotfixes for GDI32 not generally available.)
Because it's not a buffer overflow problem; and because a WMF is spooled GDI commands which is surprisingly similar to what printing is all about, so shile WMFs are not generally used, and certainly not this specific feature, it's unfortunately not obvious that just disabling the stuff will really cut it as a real patch. That's what the unofficial patch does. It's not good enough to just imitate that.
In this case, it's how an image loading library determines the type of an image it is ordered to load. If you rename a WMF to EXE, it won't load. If you rename it to JPG or BMP or PNG and feeds it to a parser relying on the shell image parsing library, the picture will be loaded.
Let me tell you something: Let's suppose I have a JPEG file on my machine. I write "mv blaha1.jpg blaha1.png". Then I choose "Open file" in Firefox and I select the file. Do you know what happens? It's rendered as a glorious image, just like I never told the system it was a PNG. Obviously the MS image library here isn't the only one that silently second-guesses the type. (I've yet to try this with a real httpd up, but I would expect identical results in FF, and IE.)
I think you misunderstand something here. What will probably appear is an additional keyword you add to a pointer variable, or another symbol in the series (*, &) to add "gced" as a possible option to "pointer, reference". Just like you can't modify the contents of a const reference, you might not be allowed to do arbitrary pointer arithmetics on a gced object, without casting it. If you do, you'll be fine. If what you used was originally a plain newed pointer, you won't even see the GC there. Optional is two pieces here -- optional that the gc framework is linked at all and optionally used for every variable. Bjarne sees this as a possibility for certain objects and I can agree there, the point of having GC in C++ would be to not worry about the deallocation of the syntax tree in the fancy parser of yours, where the consumer code is written by some other moron who may want to keep some of the subtrees, but not all of it, forever. It's not for any object that's currently allocated on the stack, absolutely not for objects encapsulating scarce outside-world (files, sockets, mapped GPU memory, db connections) resources.
It's more like a fictive scenario where only primitives and PODs were allowed on the stack. Adding stack-allocated objects would simplify a lot of scenarios and actually bring performance benefits. You'll shoot yourself in the foot if you pass a pointer to such an object to other code which might reference it after the call ends, but no-one will stop you from taking a malloced void* space and against all sense casting it into any object of your liking, avoiding constructors and all.
I really like what I read in this article and previous notes from Bjarne. I just hope that takeup (as in compiler support) might be faster this time round than with C98, both in G++ and MSVC, as those are the compilers I routinely encounter.
And this will be very little. He actually discusses this for a bit in TFA. On the other hand, compiler vendors can naturally choose to allow warning levels that clearly discourage use of obsolete or dangerous language constructs, whatever those may be. That way, your old code compiles cleanly with the right settings, but in writing new code, you can get the helping hand to stay away from the dark side.
Because it can't be done cleanly. It makes RTTI seem pale and benign, and that's still turned off in most projects. It breaks with all C tradition and you would basically need to include debug symbols for everything, including libraries, in your runtime code, as the point of mapping a string to an arbitrary variable is that it's arbitrary. In addition, you can easily do it over select domains of fields by preprocessor and templates, auto-registering stuff as it's run, in your own hashtable.
So is operator overloading. I mean, if you can write a.plus(b), you can write set_FancyPropertyName(b). Both, done correctly, are much nicer as a = a + b and a.PropertyName = b. I think the dangers of hiding side effects are more or less equivalent. It's also possible to implement properties in current C++ in a quite C#-esque manner, if you just allow a small define (and black art pointer arithmetics to use an offset).
While I would like properties, I think that GCC-esque "statements as expressions" would be great if the syntax was tidied up. Inside those, you can write a nameless class with a () operator and voilà, you have an anonymous functor. And, yes, I think that the need to place a use-once functor where it's actually used in the code would help legibility. I've seen the magical lambda and I want it in a clean language like C++!
Well, it should have been obvious in 1995 that NT5 wouldn't be released, as NT4 wasn't even released by then?
On the other hand, in 1998 NT 5 betas were out and although some things were scrapped and added (Alpha support...), NT 5 beta 2 gave a surprisingly good view of what W2K would be like. On the other hand, RPC-1 support or not is probably not a big thing, that might change, but I smell politics behind this decision...
I made a previous comparison to PostScript, and I think it's still valid. I don't know any specifics about the callback, though, but the idea of spooling rendering commands is a quite efficient way to encode an image.
The problem is how the interpreter is walled off and that you don't have any way to escape out to arbitrary machine instructions, but, as noted, PostScript is also quite like this. SVG is more declarative, but there are some function calling semantics in there for interpretation, too.
The basic analysis that this is a leftover from the 3.1 days that noone cared about is totally valid...
Do we, really? We have ECC and selectively disabling sections when we know they don't work, but do we have a scheme where one faulty transistor in the core itself will never affect operation? (Compare to how ECC might promise you no data loss desptie a n-bit error within a word.)
Data != executables. This of course still might leave some opportunity for a buffer overflow attack by modifying that data, but as the 360 actually normally runs with some memory protection (compared to the original "everything is friends down at ring 0" in the Xbox), the route into loading arbitrary code of arbitrary size may still be quite complex.
Was Windows ME ever supposed to be anything but a patch-up from 98SE and an attempt to get people used to never having a real DOS mode?
The bold vision for XP was to get the 9x users over.
NT4, 2000 and Longhorn are all projects that at one time or another were connected to huge ideas, though. They all kind of failed. On the other hand, they are all significant improvement over their predecessors. The current WinFS beta is also a whole lot closer than they ever were before -- the gap between "this is oh so cool in PowerPoint" and "this is running on your machine" isn't there, as you can have it on your machine. Trouble is, it just isn't very exciting right now. The current pitch is that no app should need its own data store, just dump it into the database. Right now, I just don't see any analysis on their part for WHY people are rolling their own data store on Windows right now, instead of using Jet (the Access engine) for everything. It will be interesting to see if they manage to make the APIs simple, yet versatile, enough to stop people from just dumping some structs into a binary file and then patch on an index as an afterthought for most consumer apps, even those that should benefit from a real database backend, if only for performance.
Well, maybe the game didn't, but obviously the gamer's love for (or obsession with) the game DID.
I think the situation is similar to several possibilities to die from drug use, where the real reason for death is not a physiological reaction outside the brain, or even a brain collapse, due to the substance, but rather the fact that the substance keeps you from keeping yourself in a living condition.
As I noted in another comment, this seems to be connected to the cafe gaming environment, which maybe makes the enjoyment more intense (or whatever, I don't really know). If it is that way, then we can just ask(/regulate) the shopkeepers to pay some attention to what their customers are doing.
If a game was released that really, with total certainty, made anyone who played it so obsessed with it that IV feeding always ended up as the only option, then I would think it would make total sense to stop it. It's not unreasonable to think that it would be possible to create something that triggered the general human nervous system that intensely, either.
Before that, it's a matter of distributing the blame. It's reasonable (without more detailde information) to place most of the blame on the poor suckers who died, but that doesn't mean that everyone who would have been able to do something about it, but didn't, should feel good about themselves. If, for example, a MMORPG allows continous login for 48 hours, that sounds like a stupid idea, even from the simple "stop the bots" perspective. If it can stop one or two involuntary suicides, that's quite nice, too.
But nothing that even approaches day/night light conditions won't exactly promote an existance with proper patterns of sleep and hormonal activity. I would venture to guess that it's more likely that it hides the normal signs of not feeling well, as the environment is abnormal in itself.
On the other hand, for that long a period, the lack of some kind of day/night rhythm could mess different signal substance levels up, for real. It won't, generally, be enough to kill on its own, but even VERY bad air won't be enough to kill on its own, either. If the body orders a low pulse, while the air is full of CO2 (or even CO), or some other messup, I would certainly think that it plays a little, but significant, part. Also, in a badly lighted room, the chance of some around you noticing your face suddenly getting very pale, or something similar, is even more slim, than if they were just playing WoW, but would be able to see your face if they looked at you for a second.
The (anti-social) geeky side of me tell me something else: Not very many seem to die from gaming in a solitary condition at home. These people are not dying from gaming for 20 days straight, they die from social gatherings, the by far most dangerous human invention ever.
I think the problem these days is that most people want to get something equal to VB apps, at least. Otherwise, they'll just do HTML with some Javascript.
And, remember, that real basic is strictly line-oriented programming. The very source of spaghetti. Bash OO all you want, but you do NOT want to get people started in that paradigm. At least teach them to use structured loops and function constructs. (Or get them into real assembler;-)
(I started in BASIC myself on a PC clone with MS-DOS 2.1 at the age of 4 or 5. I'm still trying to heal some of the scars from that experience. I think that it gave me some kind of strange intuition for formulating certain thoughts into code, though. Too bad it's BASIC code, so I have to retranslate it into Pascal (my 2nd language) in my head and then write it down as some C derivative...)
How so? Existing programs that want to be able to write to a specific HKLM key or "needs" to write to a specific file are a significant problem. The total security can sometimes be kept, while accomodating some small changes for specific apps.
No one would write a UNIX app that required root to run, but if there were a bunch of such apps, what would you do about it?
(The other option is some kind of charade where old apps would get a virtual file system and registry. That would have some advantages, but it would also be a total mess to know where something presented by an application is a real path or a virtual path in the private filesystem.)
You could disable win32k.sys in Windows XP. You just couldn't log in and many other components assumed it should be present. In Windows XP embedded, you can even get a working system with no real graphics.
Kernel mode has NOTHING to do with something being configurable. win32k.sys is just assumed to be there by many other components, while a system can do reasonably fine without beep.sys or the Sony rootkot. All are kernel mode.
Since, you know, it's really hard to run a kernel debugger? It will still be a bit complicated to debug it without remote debugging, as the display will freeze when you break into critical rendering code.
From what I've seen, the DDI interface of DirectX will still be in kernel mode. The ATI and Nvidia code will still be quite present in kernel mode.
Yeah, but that was accomplished by giving all processes (Windows 3.1 had some memory protection, you know) access to lots of common memory. You could just poke at an address with a malformed stick and mess up the contents of a different window.
In fact, it's probably easier to move it into user space now, as what they really do is to create the Avalon interface, with no IPC at the UI API level, which was present in the nice old Win32 design.
This means that, while CSRSS context switching was needed in NT 3.x, just about any rendering will do by a DLL, in the running context of the current process. They will probably just tie some frame buffer transfer code together in the kernel, or some memory mapping.
And, yes, this still makes OpenGL difficult, as the whole surface is managed by a DirectX-like system, independent of details like if it's running in user or kernel mode. Front buffer switching is still needed. That has to be coordinated.
They are all a couple of MS user mode components. That doesn't mean that they are easy to replace.
On the other hand, win32k.sys was also separated in W2K and WXP. Reverse engineering to replace it wasn't much harder or easier than replacing comctl32.dll, shell32.dll, mshtml.dll and advapi32.dll on a WXP machine. ReactOS and WINE parts can be used on a Windows system to some success, but it's basically not a matter of kernel or user mode. Kernel mode, ring 0, doesn't mean that it's all in one monolithic file. Moving to user mode, especially, doesn't make it much easier to replace.
Yeah, MS came back the second time around, when learning how to write a virtual memory, portable OS (WinNT) and a VM environment (the.NET Framework). So, this means that they will redesign the icon in 3 to 5 years time and stop sharing the Mozilla icon. They will also not allow the Mozilla foundation to use MS' new icon. I'm horrified.
Slashdot Mirror
Some interesting things done in Vista are file system transactions (possibly making a complete program install atomic, if you want to) and much better cancelling of (a)synchronous I/O. The latter part is hugely interesting, as, in my experience, an application that won't get killed is generally caused by it being stuck on an I/O syscall in the kernel. It isn't mentioned in this video for some reason, maybe because it doesn't matter to the overall kernel design; only to the I/O subsystem. Compared to some designs, the NT kernel is after all only monolithic in the sense that there is a lot of stuff running in ring 0, it's both modularized in design and linking (you don't compile a device driver into the kernel, you just load it in kernel space, that difference is actually huge).
I think we should be thankful that mainstream media is getting accurate enough to mention that it's directly related to Windows. I can't blame them for using a description of the systems affected that I know that a lot of /.ers would use. (Except for the possible tendency to write "W1nd0wz b0x3z", in some cases.)
I hope my karma burns well.
A static GDI32 patch would create more problems than this patch already might do in the area of localization and different subversions, as not everyone is using US English x86 WinXP with SP2 and every available hotfix. (On the contrary, there are even non-security hotfixes for GDI32 not generally available.)
Because it's not a buffer overflow problem; and because a WMF is spooled GDI commands which is surprisingly similar to what printing is all about, so shile WMFs are not generally used, and certainly not this specific feature, it's unfortunately not obvious that just disabling the stuff will really cut it as a real patch. That's what the unofficial patch does. It's not good enough to just imitate that.
Let me tell you something: Let's suppose I have a JPEG file on my machine. I write "mv blaha1.jpg blaha1.png". Then I choose "Open file" in Firefox and I select the file. Do you know what happens? It's rendered as a glorious image, just like I never told the system it was a PNG. Obviously the MS image library here isn't the only one that silently second-guesses the type. (I've yet to try this with a real httpd up, but I would expect identical results in FF, and IE.)
It's more like a fictive scenario where only primitives and PODs were allowed on the stack. Adding stack-allocated objects would simplify a lot of scenarios and actually bring performance benefits. You'll shoot yourself in the foot if you pass a pointer to such an object to other code which might reference it after the call ends, but no-one will stop you from taking a malloced void* space and against all sense casting it into any object of your liking, avoiding constructors and all.
I really like what I read in this article and previous notes from Bjarne. I just hope that takeup (as in compiler support) might be faster this time round than with C98, both in G++ and MSVC, as those are the compilers I routinely encounter.
And this will be very little. He actually discusses this for a bit in TFA. On the other hand, compiler vendors can naturally choose to allow warning levels that clearly discourage use of obsolete or dangerous language constructs, whatever those may be. That way, your old code compiles cleanly with the right settings, but in writing new code, you can get the helping hand to stay away from the dark side.
Because it can't be done cleanly. It makes RTTI seem pale and benign, and that's still turned off in most projects. It breaks with all C tradition and you would basically need to include debug symbols for everything, including libraries, in your runtime code, as the point of mapping a string to an arbitrary variable is that it's arbitrary. In addition, you can easily do it over select domains of fields by preprocessor and templates, auto-registering stuff as it's run, in your own hashtable.
While I would like properties, I think that GCC-esque "statements as expressions" would be great if the syntax was tidied up. Inside those, you can write a nameless class with a () operator and voilà, you have an anonymous functor. And, yes, I think that the need to place a use-once functor where it's actually used in the code would help legibility. I've seen the magical lambda and I want it in a clean language like C++!
Thanks!
On the other hand, in 1998 NT 5 betas were out and although some things were scrapped and added (Alpha support...), NT 5 beta 2 gave a surprisingly good view of what W2K would be like. On the other hand, RPC-1 support or not is probably not a big thing, that might change, but I smell politics behind this decision...
The problem is how the interpreter is walled off and that you don't have any way to escape out to arbitrary machine instructions, but, as noted, PostScript is also quite like this. SVG is more declarative, but there are some function calling semantics in there for interpretation, too.
The basic analysis that this is a leftover from the 3.1 days that noone cared about is totally valid...
Do we, really? We have ECC and selectively disabling sections when we know they don't work, but do we have a scheme where one faulty transistor in the core itself will never affect operation? (Compare to how ECC might promise you no data loss desptie a n-bit error within a word.)
Data != executables. This of course still might leave some opportunity for a buffer overflow attack by modifying that data, but as the 360 actually normally runs with some memory protection (compared to the original "everything is friends down at ring 0" in the Xbox), the route into loading arbitrary code of arbitrary size may still be quite complex.
The bold vision for XP was to get the 9x users over.
NT4, 2000 and Longhorn are all projects that at one time or another were connected to huge ideas, though. They all kind of failed. On the other hand, they are all significant improvement over their predecessors. The current WinFS beta is also a whole lot closer than they ever were before -- the gap between "this is oh so cool in PowerPoint" and "this is running on your machine" isn't there, as you can have it on your machine. Trouble is, it just isn't very exciting right now. The current pitch is that no app should need its own data store, just dump it into the database. Right now, I just don't see any analysis on their part for WHY people are rolling their own data store on Windows right now, instead of using Jet (the Access engine) for everything. It will be interesting to see if they manage to make the APIs simple, yet versatile, enough to stop people from just dumping some structs into a binary file and then patch on an index as an afterthought for most consumer apps, even those that should benefit from a real database backend, if only for performance.
I think the situation is similar to several possibilities to die from drug use, where the real reason for death is not a physiological reaction outside the brain, or even a brain collapse, due to the substance, but rather the fact that the substance keeps you from keeping yourself in a living condition.
As I noted in another comment, this seems to be connected to the cafe gaming environment, which maybe makes the enjoyment more intense (or whatever, I don't really know). If it is that way, then we can just ask(/regulate) the shopkeepers to pay some attention to what their customers are doing.
If a game was released that really, with total certainty, made anyone who played it so obsessed with it that IV feeding always ended up as the only option, then I would think it would make total sense to stop it. It's not unreasonable to think that it would be possible to create something that triggered the general human nervous system that intensely, either.
Before that, it's a matter of distributing the blame. It's reasonable (without more detailde information) to place most of the blame on the poor suckers who died, but that doesn't mean that everyone who would have been able to do something about it, but didn't, should feel good about themselves. If, for example, a MMORPG allows continous login for 48 hours, that sounds like a stupid idea, even from the simple "stop the bots" perspective. If it can stop one or two involuntary suicides, that's quite nice, too.
On the other hand, for that long a period, the lack of some kind of day/night rhythm could mess different signal substance levels up, for real. It won't, generally, be enough to kill on its own, but even VERY bad air won't be enough to kill on its own, either. If the body orders a low pulse, while the air is full of CO2 (or even CO), or some other messup, I would certainly think that it plays a little, but significant, part. Also, in a badly lighted room, the chance of some around you noticing your face suddenly getting very pale, or something similar, is even more slim, than if they were just playing WoW, but would be able to see your face if they looked at you for a second.
The (anti-social) geeky side of me tell me something else: Not very many seem to die from gaming in a solitary condition at home. These people are not dying from gaming for 20 days straight, they die from social gatherings, the by far most dangerous human invention ever.
And, remember, that real basic is strictly line-oriented programming. The very source of spaghetti. Bash OO all you want, but you do NOT want to get people started in that paradigm. At least teach them to use structured loops and function constructs. (Or get them into real assembler ;-)
(I started in BASIC myself on a PC clone with MS-DOS 2.1 at the age of 4 or 5. I'm still trying to heal some of the scars from that experience. I think that it gave me some kind of strange intuition for formulating certain thoughts into code, though. Too bad it's BASIC code, so I have to retranslate it into Pascal (my 2nd language) in my head and then write it down as some C derivative...)
No one would write a UNIX app that required root to run, but if there were a bunch of such apps, what would you do about it?
(The other option is some kind of charade where old apps would get a virtual file system and registry. That would have some advantages, but it would also be a total mess to know where something presented by an application is a real path or a virtual path in the private filesystem.)
Kernel mode has NOTHING to do with something being configurable. win32k.sys is just assumed to be there by many other components, while a system can do reasonably fine without beep.sys or the Sony rootkot. All are kernel mode.
From what I've seen, the DDI interface of DirectX will still be in kernel mode. The ATI and Nvidia code will still be quite present in kernel mode.
Yeah, but that was accomplished by giving all processes (Windows 3.1 had some memory protection, you know) access to lots of common memory. You could just poke at an address with a malformed stick and mess up the contents of a different window.
In fact, it's probably easier to move it into user space now, as what they really do is to create the Avalon interface, with no IPC at the UI API level, which was present in the nice old Win32 design.
This means that, while CSRSS context switching was needed in NT 3.x, just about any rendering will do by a DLL, in the running context of the current process. They will probably just tie some frame buffer transfer code together in the kernel, or some memory mapping.
And, yes, this still makes OpenGL difficult, as the whole surface is managed by a DirectX-like system, independent of details like if it's running in user or kernel mode. Front buffer switching is still needed. That has to be coordinated.
They are all a couple of MS user mode components. That doesn't mean that they are easy to replace.
On the other hand, win32k.sys was also separated in W2K and WXP. Reverse engineering to replace it wasn't much harder or easier than replacing comctl32.dll, shell32.dll, mshtml.dll and advapi32.dll on a WXP machine. ReactOS and WINE parts can be used on a Windows system to some success, but it's basically not a matter of kernel or user mode. Kernel mode, ring 0, doesn't mean that it's all in one monolithic file. Moving to user mode, especially, doesn't make it much easier to replace.
Yeah, MS came back the second time around, when learning how to write a virtual memory, portable OS (WinNT) and a VM environment (the .NET Framework). So, this means that they will redesign the icon in 3 to 5 years time and stop sharing the Mozilla icon. They will also not allow the Mozilla foundation to use MS' new icon. I'm horrified.