GDI and Win32 can share handles with other processes because the executive Object Manager allows you to add your own types of objects; anyone can do it. It's like Linux's VFS; would you be suprised if user programs could create files, pipes or sockets which could be shared? The difference is that NT will let you create entirely new types of objects, with new properties. The object manager handles the existance of objects and handles to them: what the objects actually do is up to the provider.
The registry is implemented in the Configuration Manager. It is an executive service, one level up from the kernel. It is this low because the device database is implemented using the registry.
In order to display onscreen, it has to be translated into pixels. Before it reaches the screen, you can describe shapes in terms of lines, curves, etc in logical coordinates without committing to a specific configuration of pixels. For example, a line one inch long might be 50 pixels long at one resoulution and 100 pixels at a higher one; the line's description says inches and you can't know how many pixels are in an inch until you have a display device in mind. The 1 inch line is device-independent because it will be 1 inch regardless of device. How a 50 pixel line looks depends on the device.
Overrunning a web browser, including Internet Explorer, won't get you root access unless you are running it in a privledged account such as Administrator. IE is just another user mode program.
There are tools available, such as runas, SUD, and psexec that let you run only specific programs (usually those that need admin access for no reason) as admin.
No it's not. See XPLite to remove all traces of IE.
The GDI is set up such that a crash in the video routines kills the whole kernel.
This is because win32 got moved into kernel mode in NT4. Before NT4, GDI ran entirely in user mode; if it crashed, noone in kernel mode even noticed. Win32 is still not, however, integrated with anything in kernel mode. All of kernel mode win32 is in win32k.sys.
By contrast, it is possible to run Linux without a single line of browser code anywhere on the system, or without any gui of any kind if you like.
Linux is a kernel only. The Windows NT kernel will happily run with no GUI. Setup (phase 2 in 80x50 text mode) and the recovery console run with the same kernel and the same drivers as IE does, but without any win32. The problem is that Win32 depends on having a GUI and there are almost no applications that can use the kernel's native API without win32.
The Windows NT kernel (same one in 2000/xp) has nothing to do with "Internet Explorer/Media Player/Instant Messenger". Microsoft whined that they couldn't be removed not because it is technically infeasable but because it is part of an 'indispensible user expierence'.
NT design 101: On the bottom, there is the kernel, then the executive, which includes the object, configuration, process, VM, I/O managers, the security ref monitor (a runtime to create tokens, check ACLs) and the local procedure call provider. After that, device drivers. After that, everything is in user mode with one exception. Then there are the intrinsic subsystems: the session manager (the init process, aka smss), the local security authority (lsass), the security accounts manager (SAM), winlogon, and the service control manager. Then the environment subsystems, namely win32. The entire syscall interface is exported to user mode by the Nt* functions in ntdll.dll. Environment subsystems translate calls from their API into native calls. Win32's environment server is hosted in csrss.exe. With NT4, the meat of win32 was moved into kernel mode (win32k.sys) to reduce context switching overhead; win32 was not then and still isn't integrated into the kernel itself. The kernel doesn't care what environment subsystems are running. After that, you have the shell components; these all run in the security context of the logged on user (subsystem components run as SYSTEM). The shell includes Internet Explorer and the start menu. On top of that (usually) are applications.
Each layer only cares about the one immediately above and below it at most. To the kernel, Internet Explorer is just another user mode program. A hole in IE cannot escilate beyond the user's privledges in the process's security context. Your machine be hosed by a hole in IE if you are running it as Admin (just as a hole in Mozilla if it was running as root), but not if it is running as a normal user. You need to exploit a local vuln in the kernel first, just like any other OS.
Look at the entire syscall interface (the Nt* functions). Tell me which functions are "directly tied into the lowest levels of the operating system".
You're wrong about that. Drivers *can* accelerate GDI+. See this article.
Eh, I guess you are right. I'm still curious as to why the same operations in GDI are 10x more efficent than in GDI+. Just simple line drawing.
I created a tetris clone in VB6; it used direct GDI calls to render the blocks. Even when modified to redraw blocks every 20ms, CPU usage is less than 3%. Later, I ported it to VB.NET and GDI+. Even normal use causes at least 40% CPU usage (80% of that user mode time). I moved the drawing commands back to GDI by creating a COM library out of the GDI classes I made for VB6 and the CPU time went back to less than 3%. I moved the hardware acceleration slider to 0 and CPU usage went up to an average of 30%. I don't understand. I'm sure I had all the AA, translation and other effects off.
Let me put this in concrete terms: GDI, I can draw a line that, according to the semantics of the GDI, passes through 10,20, then draw a white pixel at 10,20 to erase that part of the line, and expect it to work.
Yeah, I'll buy that there are applications that depend on that. It's a lot like the differences between Win16 GDI (still used in 9x) and NT GDI. The designers of NT GDI created this function for that reason. By default DCs are in GM_COMPATIBLE mode but if you want new functions you have to change it to GM_ADVANCED knowing that the semantics will change. So, a third type mode can be created, say GM_LONGHORN, that changes certain semantics such as pixel predictable rendering. Broken applications can still have GM_COMPATIBLE from Win16 and apps who are aware of it can have GM_LONGHORN. What's wrong with that plan?
Show me where on your desktop you see Bezier curves?
Ok now wait a minute, are you saying that Bezier curves aren't accelerated or that Bezier curves aren't used often? I agree that they aren't used much but I don't agree that they aren't accelerated. Besides, not using them is an artifact of popular applications not wanting to; it has nothing to do with GDI's capabilities. Do you think that Avalon will magically get apps to use Bezier curves? As for gradients, I see one at the top of every one of my windows. I think those are also accelerated because the video driver goes out of its way to handle them.
There is much more semantic information in an Avalon surface than can be described by a sequence of cached GDI calls.
Such as?
You *can* implement a scene graph on top of an immediate-mode API of course, but Avalon is designed to make the scene-graph the primary API.
It's called modular design. You can have seperate components when those seperate components do different things. One to define a format for caching, one to render them, one to decide when to render them, one to modify (IE animate) them. What's so bad about having the animation component on top of the render timing component and modification component?
You can't go into the cache and say "animate this red square by moving it 2 pixels in the x-axis every second).
What about the EMF format would prevent this from happening? Why can't I create an EMF for this red square and modify it to move +2 logical units on the x axis every second?
Look at all the things that WGF literally copies from GDI: Pens, brushes, regions, a new metafile format that does the same things, bitmaps (yes they are still there), surfaces (aka DCs)... If it's so revolutionary, why does it still have all the old components?
GDI was designed to evolve to support new features. That's why there isn't a single class for a DC: you create a DC based on another's properties usually and then you select objects in it that you care about. If a certain function just wants to draw, it doesn't have to be aware of the pen if it doesn't wan to. It can just draw. The current br
Look at it this way: if current hardware was capable of accelerating anti-aliased bezier curves, they'd accelerate GDI+. The fact that GDI+ is so slow suggests that they are not accelerating it, because 2D cores don't have that kind of capability.
GDI+ is completely different than GDI. GDI+ exists to provide better drawing to 9x while hiding the differences between 9x and NT's GDI and providing an object oriented interface, like MFC. Video drivers cannot accelerate GDI+ because they are never given an oppurtunity to. GDI does provide that opportunity using the DDI. The fact that GDI is so much faster with a vendor video driver suggests that it is accelerated while GDI+ is not.
You still haven't offered any proof as to why video drivers hook high-level drawing functions but don't actually accelerate them. You keep telling me that they aren't accelerated but have you done an actual trace or something that follows the path that the DrvXX functions take?
Currently, the only GDI acceleration utilized by most Windows software is:
I don't beleve you. My video driver says that it supports much more than that. Show me hard evidence that it is lying to me.
You could make the GDI resolution-independent by removing these semantics, but that'd break the API for applications that depend on the existing behavior.
Eh? As you said before, video output is human consumable data, not designed to be reconsumed by the computer. How can an application depend on it? How can an application be aware of how its app looks on the screen if it abstracted by a transformation that it is not aware of and cannot control? How can Avalon break those semantics yet retain compatibility but GDI cannot?
GDI was designed, from the beginning, to be resolution-indepenent, though that capability has not been excersised for video. GDI has never ever made any kind of guarntee about how your commands will be rendered on screen because of device space transformations.
Here is an example of GDI being resolution-independent: printer drivers are just another type of display driver. GDI makes absoultely no distinction in drawing commands as to wether it is a printer or video display device; the only difference is that printers get page and banding support. Your printer will undoubtedly have different DPIs that it can print at. It's funny though, even though the DPI changes, the size of the picture on the page doesn't. This is due to a device space transformation made before outputting. Try printing one logical pixel on your printer. I bet it doesn't actaully render to exactly one dot by the printer.
Why doesn't MS use GDI's scaling abilities for video? There isn't a good reason. I think they just want to make Longhorn's feature list as long as possible with as much eye candy as possible. It's the same reason that the toolbar facade looks different in every single version of Office. Microsoft wants to make it look like they are doinga lot of work to make this product better than the last.
What matters is the underlying semantics exposed by the API.
Which no one has managed to itemize. I want details; class definitions would force details.
Maybe I just don't know what to look for. Give me links to the most complete and relevant descriptions of Avalon, WGF and/or Longhorn available.
It's not caching, it's immediate-mode vs retained mode.
Retained mode means that Avalon retains the necessary instructions to draw a surface, no? In other words, it caches the drawing description instead of asking the application each time redraw is necessary. Currently, almost no caching is done by GDI; caching is only done with transparent windows and when specifically asked. Since GDI can record drawing commands into a metafile already, it wouldn't be too much trouble to ask it to maintain a cache for redrawing too. Nothing in GDI's or USER's semantics prevent this from
Hmm, that might be the case, but I don't know of any current hardware that actually does this.
How can you know that? Do you write the video drivers for all current video hardware? I still don't understand why a video driver would want to hook a rendering function only to do it in software by the CPU. If the rendering is done by the CPU anyways, then why does turning the performance slider down hurt GDI performance so much?
GDI doesn't always require pixel rendering accuracy. GDI usually defines error margins and describes how close rendering has to be to a standard. GDI provides a great deal of leeway on cosmetic lines, anti aliasing and gradients. Even if it didn't, this wouldn't be a breaking change. If Avalon doesn't have to provide predictable pixel accuracy, then why does GDI? I mean, if that support is going to be chucked anyways...
The GDI imaging model isn't the same as the enhanced metafiles imaging model. Microsoft takes some liberties with it, not the least of which is that it specifies a resolution-independent interface while GDI specifies a resolution-dependent interface. GDI can be used to draw EMF files, just like GDI can be used to draw PDF files, but there is a semantic mismatch between the two. The fundemental distinction is that "change the color of pixel 2,3 to red" makes perfect sense in the GDI imaging model, and has an expected result. It makes no sense in the PDF imaging model. The best the app can do is draw a point at 2.0, 3.0, and depending on the resolution of the screen, that might be a single pixel, a partial pixel (thanks to sub-pixel AA), or a blob of several pixels.
An EMF is just a list of GDI rendering commands. How can EMF's capibilities be different from GDI? Makes no sense... Are you trying to say that PDF doesn't support bitmaps at all? From an application, the best you can do is say change the point at logical coordinates 2,3 to red. Depending on the transformations between the logical space and the screen, it may not fill one pixel at all. All a bitmap is is a set of fixed size squares arranged in a matrix. So you are setting the square at logical coordinates (2.0,3.0)-(3.0,4.0) to red. When you set a point on a metafile, it is the same thing as in a PDF. GDI can already redirect commands to a metafile; GDI could create an EMF cache of each surface to be rendered on demand instead of immediately and it wouldn't require a rewrite.
What exactly is vague about it?
It depends on the article. I have yet to see a list (even tenative) of functions or classes that Avalon will be made up of. Various articles sing the virtures of the new system- how it will be so great and revolutionary, but fail to explain exactly how it is better. Some say that a new vector rendering engine that can cache vector images; but EMFs already do that. Some say that bitmaps will be cached and the video card will compose them based on position, region and transparency, but device surfaces and regions already do that and I'm sure bitmap caching could be added easily: bitmaps are already cached for windows behind transparencies. Expand it to everything. I have yet to find a hard list of all the capabilities that it will support, in detail. I know it is still in early development but surely Microsoft has some prototype interfaces by now?
Take this article. "Repainting vs markup": wow caching is already done by GDI in some situations, it would be easy to expand it to everything. "Vector Graphics in Avalon": they even admit that it does the same things that EMFs do, and have 2 bad reasons (which are the same) as to why this is better: binary formats are hard to work with. It's not like the for
OK I guess there is more of a difference between 3d and 2d hardware than I thought.
DrvTextOut doesn't rasterize the glyphs. It takes pre-rendered glyphs from the software font-rasterizer and alpha-blits them to the screen. This is exactly how Xft/XRender works.
No, DrvTextOut allows a display driver to handle all aspects of font rendering. Also, GDI can translate glyphs into a path (a vertex based shape) that the display driver can render.
What I'm saying is that most vendors don't bother to properly hardware-accelerate these functions (because it's hard within the confines of the GDI, and nobody uses it anyway), and supply fast software-emulation instead.
And exactly whose fault is that? The video hardware people. Like I said before, GDI is only an interface: the vendor can choose to implement it any way they want. Tell me why a vendor couldn't use the 3d hardware (and ditch the 2d hardware) on their card to support GDI?
It's not a resolution-independent API if you have to set-up the coordinate transform for resolution independence yourself. Also, you would be changing the pixel-level semantics of the GDI if you had a non-identity space transform on by default.
GDI handles device space transformations exclusively, not you. We're talking about digitial computers: the output of such computers are totally detirministic. It is not unreasonable to expect standard results from different vendors; how would you feel if Western Digital decided to not store your data correctly because hard drive technology is changning rapidly? Some consumer video cards are sloppy; you see the polygon seams and off-by-one errors on them. A professional video card is different: the output from the 3d renderer can be predicted exactly. Why do you think there is a difference; like between the GeForce and Quatro? See these screenshots. Some people would be pretty disappointed if video manufactures took it upon themselves to make arbitrary, subtle changes to rendering. GDI never guarnteed pixel level access to device surfaces. The closest thing you can get is to create a memory bitmap and try to blit it to the screen; there is no guarntee that that blit will not undergo any transformations. Why do you think they are called 'device-indepenednt bitmaps'? If Avalon can do its transformations while still maintaining compatibility, why can't GDI?
To properly support the PDF 1.4 imaging model,
What, exactly, can the PDF 1.4 imaging model do that Enhanced Metafiles can't?
Please read some of the WinHEC papers about Avalon and the Longhorn Display Driver Model (LDDM) to see why they are replacing GDI.
I try, but all the literature that I find about Avalon and Longhorn is increadibly vague.
When people say GPU, they don't mean the 2D accelerator on graphics cards, they mean the 3D accelerator. Mac, X, and Windows have used the 2D core for ages (along with every other OS under the sun). Those things aren't very interesting, and haven't improved in capability in a long time. The programmable 3D core, however, is capable enough to properly support the PDF 1.4/SVG imaging model.
There isn't that big a difference in the way 3d and 2d effects are rendered on a modern GPU. The GPU is just that: a microprocessor specialized for repetitive and paralell operations. Remember the recent articles about running programs on the GPU? Besides, what parts of the hardware that video functions use are up to the video card people; GDI is just an interface. If they want to use the '3d' hardware for 2d effects, then there is nothing stopping them. Everything is 2d by the time it reaches the screen.
In practice, nothing accelerates font-rasterization. GDI ends up doing the same thing X and MacOS do --- rasterizing the outline in software to a off-screen buffer, and simply using an alpha blit to compose the pre-rendered glyph. The lack of anti-aliasing is a limitation of the GDI design, for 2 reasons:
Yes, that is what would happen if the video driver didn't support the DrvTextOut function; the title reads "The DrvTextOut function is the entry point from GDI that calls for the driver to render a set of glyphs at specified positions." My video driver supports it; why would they support it, other than to offload to hardware? What evidence do you have that this is a sham in that this isn't really what is happening?
1) It's a pixel-exact API. It guarantees certain things about what pixels will be drawn in response to certain commands. Of course, with a resolution-independent, anti-aliased rendering engine, you can't make such guarantees.
Sure you can; it's called a "standard". I'm sorry that some other rendering engines are sloppy.
2) It's designed to use a seperate 2D engine on the card. This brings all sorts of concurrency issues between the 2D engine and 3D engine. That's why nobody release proper accelerators for GDI+ --- it's concurrency issues just make it a PITA. Some drivers do have hacks to allow things like alpha blits to use the 3D engine, but at the end of the day, these things are still hacks.
I don't think that there is a seperate 2d and 3d engine on modern GPUs. Back with the 3dfx Voodoo1 3d only cards, yes. Modern GPUs are just specialized processors.
The reason that GDI+ isn't accelerated is that it is a platform-indepent: 9x and NT's GDIs are very different so GDI+ can't depend on either. GDI+ does all the rendering itself to hide the differences.
Alpha blit support is not a hack: it is a standard function in GDI supported the same way that everything else is. Or are you saying that video driver writers have to resort to a hack to support alpha blending? This would represent a poor hardware architecture, not a problem with GDI. Do you have a specific video manufacturer that does this?
It's probably using a fast software-emulation inside the driver. And it is a problem of the GDI, because the seperate 2D and 3D driver model makes it hard to write a graphics core that can use the 3D core's evaluators to draw curves in hardware.
So the video driver says that it supports it-- but no that isn't possible for some (undisclosed) reason! It must be a lie! Seriously, do you have some actual evidence of this? Is there some reason that the GPU can't do alpha blits on demand? Why would the video driver people want to handle alpha blending in their driver if they couldn't offload it to hardware; what would be the point?
A second generation display layer does not maintain vector information about the shapes it draws. If an application running in an OS with a second generation display layer wants to perform similar graphical transformations, it must implement a third generation display layer within itself. Examples of this include vector drawing applications like Adobe Illustrator and Macromedia Freehand. Each application must roll its own vector graphics solution because the second generations display layers in Mac OS and Windows do not support these features.
An Enhanced Metafile stores a list of vectored drawing commands, exactly like a PDF does. All the transformations that Quartz can do to a PDF, GDI can do to a EMF. EMFs are supported in all versions of Windows NT. Since GDI can already redirect all drawing commands to an EMF, it would be easy for GDI to maintain an EMF cache of a surface, ready to be redrawn at any time. They are called 'enhanced' because they use NT's GDI functions as opposed to Win16's functions. The format for an EMF is open and GDI provides copious functions to view, edit and transform metafiles. GDI is capable of doing everything that Quartz's drawing engine does in the article.
[In Quartz Extreme,] Rendering is still done via the CPU --- OpenGL is used only at the very last step, where the transparent windows are composited together.
This will change in OS X 10.4, or so I've heard, which will, like Longhorn and Cairo, use the GPU for 2D rendering acceleration.
I read this as saying that GPU rendering acceleration won't be available until OSX 10.4, Longhorn(Avalon) and Cairo. I disagreed with this since GDI can already use the GPU for 2d rendering.
GDI doesn't do anti-aliasing either.
GDI supports accelerated anti-aliasing of fonts (not paths) using the FO_GRAY16 member of the FONTOBJ font description structure. I don't know why paths aren't anti-aliasable, but I'm sure that MS could add that function with a new device cap and a new path property fairly easily. This isn't a limitation of GDI's design.
2) Most drivers don't accelerate the curve and gradient portions of the GDI. GDI+ was designed to foster that, but nobody accelerated that either. That's why Microsoft just decided to use Direct3D to accelerate Avalon.
According to GetDeviceCaps my video card (a GF3Ti200) supports drawing of both curves and gradients. Even if it didn't, this is the video driver maker's problem, not GDI's.
GDI+ is a user mode rendering library that does all the rendering in software, by itself. It has little relation to GDI. This is why.NET takes at least x50 the cpu usage to render vector graphics since the System.Graphics.Drawing class uses GDI+ exclusively. I think it's stupid; everything that GDI+ does, normal GDI does or could be easily modified to do. I think the main point of GDI+ was to make better video functions available on 9x/w Microsoft lock-in.
1) It doesn't have the same imaging model. GDI is a 2nd generation display technology. Cairo and Quartz2D are a third generation (resolution-independent) display technology.
However, while 2nd-gen apps were fine with acceleration of aliased-lines, and simple fills and blits (which is what GDI and XAA provide), such meagre functionality doesn't cut it for 3rd gen display technologies like Avalon, Cairo, and Quartz.
GDI already has all the base functionaility needed to support resolution-independent display technology, in the form of coordinate space translations. Unfortunately, these translations are woefully underused. The fact that USER ignores them doesn't help any. Still, these things are not part of GDI; GDI shouldn't be blamed for them.
I'm curious about what it is that makes 'third-generation' rendering engines so great? What is it that these do that GDI either cannot already do or couldn't be made to do easily? (without a rewrite)
Personally, I think that development time spent on Avalon is seriously misplaced as it is replacing a component that isn't broken to create more eye-candy. Maybe I'm missing something. Sorry about chopping up your posts.
Assuming your display driver supports it, GDI can already offload almost all drawing, clipping, and transformations to the GPU. GDI will call as many of these (see the list on the left) functions as the driver supports. Where hardware support is unavailable, rendering will be done in software.
GDI can negotiate with the driver to decide on which operations to accelerate. Let's say your video hardware can draw lines but not curves. No problem: GDI will convert any curves to be rendered into a series of lines. Also, a driver can decide at any time that an operation is too complex and direct GDI to simplify it by a process known as punting.
All of this has existed since NT 3.1, although alpha blending and gradient fills weren't supported until Windows 2000.
I think this is one of the great things about Slashdot: once you post something, it cannot be changed or removed, not by you nor by anyone else. The only thing you can do is add more by replying. A Slashdot user isn't as strong identification as an academic identity, but it is something and it is difficult to impersonate.
Re:You hate it because you cant effectively argue
on
Ballmer on Linux
·
· Score: 1
No, it really is. Are you honestly going to try to argue that one can treat any OS as being equal when it comes to arguing security. Just because Linux and Windows are both operating systems does not allow you to argue that they therefore have the same security strengths/weaknesses.
Without specific details, you can't compare two operating systems at all; you cannot make a statement for or against equaility. Details have been very sparse in this thread.
Again, very wrong. Linux is based on a UNIX OS design, one that assumes user groups and individual logins from the get-go. Windows is based on a single-user environment, where most applications won't even install correctly unless the user is root. This gives Linux a huge head start when it comes to security.
Windows NT has always assumed user groups and individual logons, it has always required ACL based security descriptors on all objects (from files to threads to mutants...). Windows NT has always been multi user in the sense that multiple users can be logged on at once. GUI support for multiple users didn't come until NT3.51 but surely Linux is still multi user without X? What are based on a single user environment is most third party applications for Windows. Programs designed to run in the monouser (no security) 9x environment whose developers are too cheap to fix their broken products. It's the application's fault that they can't install as root; it's the application's fault that it demands unreasonable access to install. The operating system isn't preventing a user from installing a program for himself; it's the installer that doesn't understand a multi user OS. If you tried to run an installer designed the same way on Linux, it would require root, replace shared libraries with bogus versions and screw with/etc. But this isn't about third party apps, it's about operating systems: both Linux and Windows protect global settings from change by normal users.
Oh, thank you so much for specifying how I can reply to you. I'm honoured.
And what is so bad about asking you to provide actual backup for your statements?
Jesus you are a giant tool. Where's your qualifications? Actually, never mind those, where is your common sense? If you want to claim Linux is as insecure (or more) than Windows, the onus is on you to prove this. There is no evidence for it now.
It depends on what aspect of security you are talking about. Design: Kernel level security in both OSes is designed to be air tight. With ACLs (NT standard, Linux/w patch) you can have a great deal of granularity. Network security design depends on what services you use: some like telnet are insecure. Both OSes provide securely designed network services. Neither OS provides any protection from root users. Both OSes provide excellent protection for the system itself and for other users from normal users. Neither OS provides more than obscurity protection for a user from himself (IE deleting all his files) Both OSes have historically provided poor protection for a user from social engineering or good ole stupidity, but both are getting better. At this point, I'd have to say that Linux is better although XPSP2 helps a lot. Linux mostly gets points here for being obscure. Both OSes provide some physical protection in the form of encryption. As for implementation: Both kernels have had a few local exploits, but not many and they didn't last long. Both have had some remote exploits too, but I think Windows is definately worse in this respect. Windows RPC has had more exploits than I can remember. For one thing, Microsoft depends on interface obscurity too often. Internet explorer has problems that haven't been fixed for some time now. The most this can escilate to is running arbitrary code as the current user (not root) so this threat can be eliminated by running IE as a different user (along
How the video is accelerated is up to the video card people. If they want to use the card's 3d hardware, that's up to them. To render a transparent polygon, the video card has to do an alpha blend op between a texture and the background; that same operation can be done without a polygon. I don't think that the 2d/3d parts of a video card are as distinct as you imply. GPU stands for graphics processor; it is just a processing device optomized for matrix and repetetive calculations. The video driver can have things processed any way it likes. Just because the frontend is OpenGL doesn't mean it isn't implemented the same way on the video hardware.
While it maybe bitmap based Quartz itself is based on the adobe PDF engine, which renders both vector and bitmap via the computers 3d card.
Everything that PDF can do for rendering, so can a Windows Metafile. Yes, this includes complex vector graphics, text, bitmaps and transformations(scaling, rotation, shearing). Notice that it has been supported since NT 3.1. As for video acceleration, GDI can use a video driver to offload many functions onto hardware, including: Alpha blending Filling paths Fill gradients Draw lines Move, set the mouse cursor Scale bitmaps Render text Render transparencies Stretch with raster op Set arbitrary surface transformations including translation, scaling, rotation and shearing Outline a path Note that all the linked functions are implemented by the video driver, not GDI. If a video driver doesn't support a feature, GDI breaks it down in software into the most complex format supported. What can Quartz Extreme do that Windows NT couldn't since 3.1? There are a few small things but nothing major.
But when is it used? It's used by the OS whenever a window is moved on a Macintosh.
Whenever a window is moved in Windows, GDI tells the driver to blit the old window position to one. If the video driver doesn't have a cache of what newly exposed areas look like (or doesn't support device bitmap caching), it gets USER to ask applications to repaint any uncovered parts of their windows. Every time a program calls something like TextOut or DrawLine, it can be accelerated.
This is about more than transparency.
Did you follow some of the links in the TOC on the left side of the page? This structure and this structure (which points to these functions) list of all the things that GDI can ask a video driver to accelerate; a list of functions and a bitmask of physical capabilities. You can query a DC to find out what it can do with this function. It ranges from a minimum of raster blitting, to rendering of paths that contain geometric bezier curves to font rendering and compression. A video driver that supports all of these things can handle all the drawing operations necessary to draw any window in hardware. Take the Mozilla window I'm typing in right now; it has a gradient title bar, much text, lines, all of which can offloaded into hardware (if the driver supports it). Or did you have somthing else in mind when you mentioned more?
Yeah. I'll be really disappointed with Longhorn if it is just another shell environment on top of win32; win32 had better become an optional compatibility layer, like win16 in NT.
As for quaility control, I would hope that.NET would mitigate some of the old problems, but so far they seem to be botching their library design. Take WindowsForms.ListBox. It would be logical for each ListItem to have a Picture property that uses an Image object, but no. You still have to construct an entire image list and maintain indexes. Dynamic loading of images is a nightmare; you have to track the references yourself because indexes are not references so are not garbage collected. If Longhorn is full of this nonsense, it'll never work.
I agree that Longhorn seems to be taking an awefully long time to get to a (buggy) first release. It could be a symptom of bigger problems.
I guess what you are saying is that UNIX already works, so people should switch to that. No argument here. Microsoft seems to be spending a great deal of effort on fixing things that aren't broken, like the video engine. GDI already does, or could easily be modified to do, all the things that Avalon is supposed to do, and without a rewrite.
What's so great about UNIX? Native Windows NT is already a modern operating system base; it is already debugged and stable. All the compatibility is in the win32 subsystem. Win32 is not part of the kernel. Longhorn is planning to replace win32 as the primary subsystem, and keep win32 only for compatibility. When NT 3.1 was released (the first version) win32 really was WINE for NT.
The problems with Windows are not with the kernel. Why would Microsoft want to replace it with UNIX?
Windows NT's GDI has always (since NT3.1) provided the opportunity for drivers to handle high level video requests themselves so they can offload to the GPU.
The optional driver support function for transparency is DrvAlphaBlend. It has existed since Windows 2000. I think that NT3.1 existed a little bit before Quartz.
I could change the shell, but I would be missing some critical core functionality.
Such as?
Go ahead, remove all the libraries that make up Internet Explorer, change the shell to cmd.exe and nothing outside of the shell will break. Delete shell32.dll, msi.dll, netshell.dll, shdocvw.dll, browseui.dll, explorer.exe, userenv.dll, urlmon.dll, shlwapi.dll, webcheck.dll, mshtml.dll and anything else you find that implements IE; nothing server-side will break.
Scaling? World transformations that provide scaling, rotation and shearing have always (since NT3.1) existed. Why isn't it used more often? IDK, but I'm sure they could start using it without a complete rewrite. Acceleration? Driver capability negotiation has always been implemented. DirectX also supports many optimizations. Possible movement of the window manager into user mode? I'm sure that win32k.sys could be moved back into winsrv.dll like it was before NT4. Graphics composition (IE caching of window data to avoid application refresh)? Trivial redirection of video ops to a memory DC and the fact that transparency is already supported without refreshing the lower window, tell me that this could be accomplished without a rewrite too. Besides, I don't know if I like the idea of spending all that memory on storing large bitmaps of how each window looks. Vector based drawing? Enhanced Metafiles have always been supported in NT. You can easily redirect the output (all GDI commands can be recorded) of a progam into a EMF, view/edit the records and play it back any time, even with a world transformation. Use 3d polygons instead of a 2d frame buffer? This would require considerable modification but only to the way that regions are computed; you can already put direct3d objects in a window with a polygonal region around the edges. One way or the other, you are still outputting to a 2d surface. And really, what is the point? Woo 3d icons.
Really, what is so broken about GDI that it needs to be replaced? IMO, there are far more important things to be overhauled in Windows than the video system. Rewriting a major component to provide eye candy should be a very low priority.
Another thing is that Avalon does not fill the same role as GDI does; Avalon also does what USER does and some shell stuff too. I'm saying that the important things in Avalon could be implemented using GDI.
But why is race a component? Technically, race is completely arbitrary to anything important in a person. Ideally, everyone would recognize that and never let it make a difference. But in the real world, there is a connection between race and material perceptions. For some reason, a person's race is an important part of their social identity; even though it is arbitrary. I think this may be partly because it is usually easy to identify someone by their race, just by their appearance. It's easy to create a stereotype associating the race to something since it is so easy to detect.
Take a group of people that are poor. The people in the community identify with each other; they favor members inside of the group over those outside. They all live near each other, since they favor the in-group. Their state of being poor has a great deal of momentum that cannot be easily changed: good education is requried for good income but the local schools have no money because the community is poor, higher education is difficult/impossible because no one can afford it, community services like police are weak and it contributes to crime and poor land value. Low land value further encourages the community to stay together because they cannot afford to move out. Social identity in the community is strong due to interdependence. People don't leave because 'abandoning' the community is stigmatized and members of the community are stigmatized. However, the strongest thing tying them together is easy identification of members of the community; even if that method is somethimes inaccurate, namely race.
If it was too hard to identify members of the in-group, the whole thing would fall apart. Other things like clothing, cars, houses, jewelery also serve to make identification easy. Also, members of more prosperous groups try to avoid being identified with the other group with expensive items the others can't afford.
Uniforms attempt to control identification by appearance: the military uses different uniforms and emblems to identify members by merit (rank). School uniforms try to mute the advantages of wealthy children by removing easy avenues to flaunt it with expensive clothing.
IMO, any attempt to create a relationship between something arbitrary (like race) to something material (like ability) is wrong. This includes positive connections: it always disgusts me to hear that I should have 'pride in my race' or whatever. What does race have to do with pride? Any kind of group identification not completely and directly related to every member of a group creates arbitrary barriers between people. It's those barriers that should be attacked, along with momentum that creates and maintains bad conditions. How to implement it? I have no idea.
Slashdot Mirror
GDI and Win32 can share handles with other processes because the executive Object Manager allows you to add your own types of objects; anyone can do it. It's like Linux's VFS; would you be suprised if user programs could create files, pipes or sockets which could be shared? The difference is that NT will let you create entirely new types of objects, with new properties. The object manager handles the existance of objects and handles to them: what the objects actually do is up to the provider.
The registry is implemented in the Configuration Manager. It is an executive service, one level up from the kernel. It is this low because the device database is implemented using the registry.
In order to display onscreen, it has to be translated into pixels. Before it reaches the screen, you can describe shapes in terms of lines, curves, etc in logical coordinates without committing to a specific configuration of pixels. For example, a line one inch long might be 50 pixels long at one resoulution and 100 pixels at a higher one; the line's description says inches and you can't know how many pixels are in an inch until you have a display device in mind. The 1 inch line is device-independent because it will be 1 inch regardless of device. How a 50 pixel line looks depends on the device.
Overrunning a web browser, including Internet Explorer, won't get you root access unless you are running it in a privledged account such as Administrator. IE is just another user mode program.
There are tools available, such as runas, SUD, and psexec that let you run only specific programs (usually those that need admin access for no reason) as admin.
The Windows NT kernel (same one in 2000/xp) has nothing to do with "Internet Explorer/Media Player/Instant Messenger". Microsoft whined that they couldn't be removed not because it is technically infeasable but because it is part of an 'indispensible user expierence'.
NT design 101: On the bottom, there is the kernel, then the executive, which includes the object, configuration, process, VM, I/O managers, the security ref monitor (a runtime to create tokens, check ACLs) and the local procedure call provider. After that, device drivers. After that, everything is in user mode with one exception. Then there are the intrinsic subsystems: the session manager (the init process, aka smss), the local security authority (lsass), the security accounts manager (SAM), winlogon, and the service control manager. Then the environment subsystems, namely win32. The entire syscall interface is exported to user mode by the Nt* functions in ntdll.dll. Environment subsystems translate calls from their API into native calls. Win32's environment server is hosted in csrss.exe. With NT4, the meat of win32 was moved into kernel mode (win32k.sys) to reduce context switching overhead; win32 was not then and still isn't integrated into the kernel itself. The kernel doesn't care what environment subsystems are running. After that, you have the shell components; these all run in the security context of the logged on user (subsystem components run as SYSTEM). The shell includes Internet Explorer and the start menu. On top of that (usually) are applications.
Each layer only cares about the one immediately above and below it at most. To the kernel, Internet Explorer is just another user mode program. A hole in IE cannot escilate beyond the user's privledges in the process's security context. Your machine be hosed by a hole in IE if you are running it as Admin (just as a hole in Mozilla if it was running as root), but not if it is running as a normal user. You need to exploit a local vuln in the kernel first, just like any other OS.
Look at the entire syscall interface (the Nt* functions). Tell me which functions are "directly tied into the lowest levels of the operating system".
Eh, I guess you are right. I'm still curious as to why the same operations in GDI are 10x more efficent than in GDI+. Just simple line drawing.
I created a tetris clone in VB6; it used direct GDI calls to render the blocks. Even when modified to redraw blocks every 20ms, CPU usage is less than 3%. Later, I ported it to VB.NET and GDI+. Even normal use causes at least 40% CPU usage (80% of that user mode time). I moved the drawing commands back to GDI by creating a COM library out of the GDI classes I made for VB6 and the CPU time went back to less than 3%. I moved the hardware acceleration slider to 0 and CPU usage went up to an average of 30%. I don't understand. I'm sure I had all the AA, translation and other effects off.
Yeah, I'll buy that there are applications that depend on that. It's a lot like the differences between Win16 GDI (still used in 9x) and NT GDI. The designers of NT GDI created this function for that reason. By default DCs are in GM_COMPATIBLE mode but if you want new functions you have to change it to GM_ADVANCED knowing that the semantics will change. So, a third type mode can be created, say GM_LONGHORN, that changes certain semantics such as pixel predictable rendering. Broken applications can still have GM_COMPATIBLE from Win16 and apps who are aware of it can have GM_LONGHORN. What's wrong with that plan?
Ok now wait a minute, are you saying that Bezier curves aren't accelerated or that Bezier curves aren't used often? I agree that they aren't used much but I don't agree that they aren't accelerated. Besides, not using them is an artifact of popular applications not wanting to; it has nothing to do with GDI's capabilities. Do you think that Avalon will magically get apps to use Bezier curves?
As for gradients, I see one at the top of every one of my windows. I think those are also accelerated because the video driver goes out of its way to handle them.
Such as?
It's called modular design. You can have seperate components when those seperate components do different things. One to define a format for caching, one to render them, one to decide when to render them, one to modify (IE animate) them. What's so bad about having the animation component on top of the render timing component and modification component?
What about the EMF format would prevent this from happening? Why can't I create an EMF for this red square and modify it to move +2 logical units on the x axis every second?
Look at all the things that WGF literally copies from GDI: Pens, brushes, regions, a new metafile format that does the same things, bitmaps (yes they are still there), surfaces (aka DCs)... If it's so revolutionary, why does it still have all the old components?
GDI was designed to evolve to support new features. That's why there isn't a single class for a DC: you create a DC based on another's properties usually and then you select objects in it that you care about. If a certain function just wants to draw, it doesn't have to be aware of the pen if it doesn't wan to. It can just draw. The current br
GDI+ is completely different than GDI. GDI+ exists to provide better drawing to 9x while hiding the differences between 9x and NT's GDI and providing an object oriented interface, like MFC. Video drivers cannot accelerate GDI+ because they are never given an oppurtunity to. GDI does provide that opportunity using the DDI. The fact that GDI is so much faster with a vendor video driver suggests that it is accelerated while GDI+ is not.
You still haven't offered any proof as to why video drivers hook high-level drawing functions but don't actually accelerate them. You keep telling me that they aren't accelerated but have you done an actual trace or something that follows the path that the DrvXX functions take?
I don't beleve you. My video driver says that it supports much more than that. Show me hard evidence that it is lying to me.
Eh? As you said before, video output is human consumable data, not designed to be reconsumed by the computer. How can an application depend on it? How can an application be aware of how its app looks on the screen if it abstracted by a transformation that it is not aware of and cannot control? How can Avalon break those semantics yet retain compatibility but GDI cannot?
GDI was designed, from the beginning, to be resolution-indepenent, though that capability has not been excersised for video. GDI has never ever made any kind of guarntee about how your commands will be rendered on screen because of device space transformations.
Here is an example of GDI being resolution-independent: printer drivers are just another type of display driver. GDI makes absoultely no distinction in drawing commands as to wether it is a printer or video display device; the only difference is that printers get page and banding support. Your printer will undoubtedly have different DPIs that it can print at. It's funny though, even though the DPI changes, the size of the picture on the page doesn't. This is due to a device space transformation made before outputting. Try printing one logical pixel on your printer. I bet it doesn't actaully render to exactly one dot by the printer.
Why doesn't MS use GDI's scaling abilities for video? There isn't a good reason. I think they just want to make Longhorn's feature list as long as possible with as much eye candy as possible. It's the same reason that the toolbar facade looks different in every single version of Office. Microsoft wants to make it look like they are doinga lot of work to make this product better than the last.
Which no one has managed to itemize. I want details; class definitions would force details.
Maybe I just don't know what to look for. Give me links to the most complete and relevant descriptions of Avalon, WGF and/or Longhorn available.
Retained mode means that Avalon retains the necessary instructions to draw a surface, no? In other words, it caches the drawing description instead of asking the application each time redraw is necessary. Currently, almost no caching is done by GDI; caching is only done with transparent windows and when specifically asked. Since GDI can record drawing commands into a metafile already, it wouldn't be too much trouble to ask it to maintain a cache for redrawing too. Nothing in GDI's or USER's semantics prevent this from
How can you know that? Do you write the video drivers for all current video hardware?
I still don't understand why a video driver would want to hook a rendering function only to do it in software by the CPU. If the rendering is done by the CPU anyways, then why does turning the performance slider down hurt GDI performance so much?
GDI doesn't always require pixel rendering accuracy. GDI usually defines error margins and describes how close rendering has to be to a standard. GDI provides a great deal of leeway on cosmetic lines, anti aliasing and gradients.
Even if it didn't, this wouldn't be a breaking change. If Avalon doesn't have to provide predictable pixel accuracy, then why does GDI? I mean, if that support is going to be chucked anyways...
An EMF is just a list of GDI rendering commands. How can EMF's capibilities be different from GDI?
Makes no sense... Are you trying to say that PDF doesn't support bitmaps at all?
From an application, the best you can do is say change the point at logical coordinates 2,3 to red. Depending on the transformations between the logical space and the screen, it may not fill one pixel at all. All a bitmap is is a set of fixed size squares arranged in a matrix. So you are setting the square at logical coordinates (2.0,3.0)-(3.0,4.0) to red. When you set a point on a metafile, it is the same thing as in a PDF. GDI can already redirect commands to a metafile; GDI could create an EMF cache of each surface to be rendered on demand instead of immediately and it wouldn't require a rewrite.
It depends on the article.
I have yet to see a list (even tenative) of functions or classes that Avalon will be made up of.
Various articles sing the virtures of the new system- how it will be so great and revolutionary, but fail to explain exactly how it is better.
Some say that a new vector rendering engine that can cache vector images; but EMFs already do that.
Some say that bitmaps will be cached and the video card will compose them based on position, region and transparency, but device surfaces and regions already do that and I'm sure bitmap caching could be added easily: bitmaps are already cached for windows behind transparencies. Expand it to everything.
I have yet to find a hard list of all the capabilities that it will support, in detail.
I know it is still in early development but surely Microsoft has some prototype interfaces by now?
Take this article. "Repainting vs markup": wow caching is already done by GDI in some situations, it would be easy to expand it to everything.
"Vector Graphics in Avalon": they even admit that it does the same things that EMFs do, and have 2 bad reasons (which are the same) as to why this is better: binary formats are hard to work with. It's not like the for
Like I said before, GDI is only an interface: the vendor can choose to implement it any way they want. Tell me why a vendor couldn't use the 3d hardware (and ditch the 2d hardware) on their card to support GDI?GDI handles device space transformations exclusively, not you.
We're talking about digitial computers: the output of such computers are totally detirministic. It is not unreasonable to expect standard results from different vendors; how would you feel if Western Digital decided to not store your data correctly because hard drive technology is changning rapidly?
Some consumer video cards are sloppy; you see the polygon seams and off-by-one errors on them. A professional video card is different: the output from the 3d renderer can be predicted exactly. Why do you think there is a difference; like between the GeForce and Quatro? See these screenshots. Some people would be pretty disappointed if video manufactures took it upon themselves to make arbitrary, subtle changes to rendering.
GDI never guarnteed pixel level access to device surfaces. The closest thing you can get is to create a memory bitmap and try to blit it to the screen; there is no guarntee that that blit will not undergo any transformations. Why do you think they are called 'device-indepenednt bitmaps'?
If Avalon can do its transformations while still maintaining compatibility, why can't GDI?What, exactly, can the PDF 1.4 imaging model do that Enhanced Metafiles can't?I try, but all the literature that I find about Avalon and Longhorn is increadibly vague.
There isn't that big a difference in the way 3d and 2d effects are rendered on a modern GPU. The GPU is just that: a microprocessor specialized for repetitive and paralell operations. Remember the recent articles about running programs on the GPU? Besides, what parts of the hardware that video functions use are up to the video card people; GDI is just an interface. If they want to use the '3d' hardware for 2d effects, then there is nothing stopping them. Everything is 2d by the time it reaches the screen.
Yes, that is what would happen if the video driver didn't support the DrvTextOut function; the title reads "The DrvTextOut function is the entry point from GDI that calls for the driver to render a set of glyphs at specified positions." My video driver supports it; why would they support it, other than to offload to hardware? What evidence do you have that this is a sham in that this isn't really what is happening?
Sure you can; it's called a "standard". I'm sorry that some other rendering engines are sloppy.
I don't think that there is a seperate 2d and 3d engine on modern GPUs. Back with the 3dfx Voodoo1 3d only cards, yes. Modern GPUs are just specialized processors.
The reason that GDI+ isn't accelerated is that it is a platform-indepent: 9x and NT's GDIs are very different so GDI+ can't depend on either. GDI+ does all the rendering itself to hide the differences.
Alpha blit support is not a hack: it is a standard function in GDI supported the same way that everything else is. Or are you saying that video driver writers have to resort to a hack to support alpha blending? This would represent a poor hardware architecture, not a problem with GDI. Do you have a specific video manufacturer that does this?
So the video driver says that it supports it-- but no that isn't possible for some (undisclosed) reason! It must be a lie! Seriously, do you have some actual evidence of this? Is there some reason that the GPU can't do alpha blits on demand? Why would the video driver people want to handle alpha blending in their driver if they couldn't offload it to hardware; what would be the point?
There aren't seperate 2d and 3d drivers. The GDI
GDI+ is a user mode rendering library that does all the rendering in software, by itself. It has little relation to GDI. This is why
I'm curious about what it is that makes 'third-generation' rendering engines so great? What is it that these do that GDI either cannot already do or couldn't be made to do easily? (without a rewrite)
Personally, I think that development time spent on Avalon is seriously misplaced as it is replacing a component that isn't broken to create more eye-candy. Maybe I'm missing something.
Sorry about chopping up your posts.
Assuming your display driver supports it, GDI can already offload almost all drawing, clipping, and transformations to the GPU. GDI will call as many of these (see the list on the left) functions as the driver supports. Where hardware support is unavailable, rendering will be done in software.
GDI can negotiate with the driver to decide on which operations to accelerate. Let's say your video hardware can draw lines but not curves. No problem: GDI will convert any curves to be rendered into a series of lines. Also, a driver can decide at any time that an operation is too complex and direct GDI to simplify it by a process known as punting.
All of this has existed since NT 3.1, although alpha blending and gradient fills weren't supported until Windows 2000.
I think this is one of the great things about Slashdot: once you post something, it cannot be changed or removed, not by you nor by anyone else. The only thing you can do is add more by replying.
A Slashdot user isn't as strong identification as an academic identity, but it is something and it is difficult to impersonate.
Without specific details, you can't compare two operating systems at all; you cannot make a statement for or against equaility. Details have been very sparse in this thread.
Windows NT has always assumed user groups and individual logons, it has always required ACL based security descriptors on all objects (from files to threads to mutants...). Windows NT has always been multi user in the sense that multiple users can be logged on at once. GUI support for multiple users didn't come until NT3.51 but surely Linux is still multi user without X? /etc.
What are based on a single user environment is most third party applications for Windows. Programs designed to run in the monouser (no security) 9x environment whose developers are too cheap to fix their broken products.
It's the application's fault that they can't install as root; it's the application's fault that it demands unreasonable access to install. The operating system isn't preventing a user from installing a program for himself; it's the installer that doesn't understand a multi user OS. If you tried to run an installer designed the same way on Linux, it would require root, replace shared libraries with bogus versions and screw with
But this isn't about third party apps, it's about operating systems: both Linux and Windows protect global settings from change by normal users.
And what is so bad about asking you to provide actual backup for your statements?
It depends on what aspect of security you are talking about. Design: /w patch) you can have a great deal of granularity.
Kernel level security in both OSes is designed to be air tight. With ACLs (NT standard, Linux
Network security design depends on what services you use: some like telnet are insecure. Both OSes provide securely designed network services.
Neither OS provides any protection from root users.
Both OSes provide excellent protection for the system itself and for other users from normal users.
Neither OS provides more than obscurity protection for a user from himself (IE deleting all his files)
Both OSes have historically provided poor protection for a user from social engineering or good ole stupidity, but both are getting better. At this point, I'd have to say that Linux is better although XPSP2 helps a lot. Linux mostly gets points here for being obscure.
Both OSes provide some physical protection in the form of encryption.
As for implementation:
Both kernels have had a few local exploits, but not many and they didn't last long.
Both have had some remote exploits too, but I think Windows is definately worse in this respect. Windows RPC has had more exploits than I can remember. For one thing, Microsoft depends on interface obscurity too often.
Internet explorer has problems that haven't been fixed for some time now. The most this can escilate to is running arbitrary code as the current user (not root) so this threat can be eliminated by running IE as a different user (along
How the video is accelerated is up to the video card people. If they want to use the card's 3d hardware, that's up to them. To render a transparent polygon, the video card has to do an alpha blend op between a texture and the background; that same operation can be done without a polygon. I don't think that the 2d/3d parts of a video card are as distinct as you imply. GPU stands for graphics processor; it is just a processing device optomized for matrix and repetetive calculations. The video driver can have things processed any way it likes. Just because the frontend is OpenGL doesn't mean it isn't implemented the same way on the video hardware.
Alpha blending
Filling paths
Fill gradients
Draw lines
Move, set the mouse cursor
Scale bitmaps
Render text
Render transparencies
Stretch with raster op
Set arbitrary surface transformations including translation, scaling, rotation and shearing
Outline a path
Note that all the linked functions are implemented by the video driver, not GDI. If a video driver doesn't support a feature, GDI breaks it down in software into the most complex format supported.
What can Quartz Extreme do that Windows NT couldn't since 3.1? There are a few small things but nothing major.
Or did you have somthing else in mind when you mentioned more?
Yeah. I'll be really disappointed with Longhorn if it is just another shell environment on top of win32; win32 had better become an optional compatibility layer, like win16 in NT.
.NET would mitigate some of the old problems, but so far they seem to be botching their library design.
As for quaility control, I would hope that
Take WindowsForms.ListBox. It would be logical for each ListItem to have a Picture property that uses an Image object, but no. You still have to construct an entire image list and maintain indexes. Dynamic loading of images is a nightmare; you have to track the references yourself because indexes are not references so are not garbage collected. If Longhorn is full of this nonsense, it'll never work.
I agree that Longhorn seems to be taking an awefully long time to get to a (buggy) first release. It could be a symptom of bigger problems.
I guess what you are saying is that UNIX already works, so people should switch to that. No argument here.
Microsoft seems to be spending a great deal of effort on fixing things that aren't broken, like the video engine. GDI already does, or could easily be modified to do, all the things that Avalon is supposed to do, and without a rewrite.
What's so great about UNIX? Native Windows NT is already a modern operating system base; it is already debugged and stable. All the compatibility is in the win32 subsystem. Win32 is not part of the kernel. Longhorn is planning to replace win32 as the primary subsystem, and keep win32 only for compatibility. When NT 3.1 was released (the first version) win32 really was WINE for NT.
The problems with Windows are not with the kernel. Why would Microsoft want to replace it with UNIX?
Windows NT's GDI has always (since NT3.1) provided the opportunity for drivers to handle high level video requests themselves so they can offload to the GPU.
This is accomplished using Capability Negotiation.
The optional driver support function for transparency is DrvAlphaBlend. It has existed since Windows 2000.
I think that NT3.1 existed a little bit before Quartz.
Go ahead, remove all the libraries that make up Internet Explorer, change the shell to cmd.exe and nothing outside of the shell will break. Delete shell32.dll, msi.dll, netshell.dll, shdocvw.dll, browseui.dll, explorer.exe, userenv.dll, urlmon.dll, shlwapi.dll, webcheck.dll, mshtml.dll and anything else you find that implements IE; nothing server-side will break.
I don't understand what is so bad about NT GDI.
Scaling? World transformations that provide scaling, rotation and shearing have always (since NT3.1) existed. Why isn't it used more often? IDK, but I'm sure they could start using it without a complete rewrite.
Acceleration? Driver capability negotiation has always been implemented. DirectX also supports many optimizations.
Possible movement of the window manager into user mode? I'm sure that win32k.sys could be moved back into winsrv.dll like it was before NT4.
Graphics composition (IE caching of window data to avoid application refresh)? Trivial redirection of video ops to a memory DC and the fact that transparency is already supported without refreshing the lower window, tell me that this could be accomplished without a rewrite too. Besides, I don't know if I like the idea of spending all that memory on storing large bitmaps of how each window looks.
Vector based drawing? Enhanced Metafiles have always been supported in NT. You can easily redirect the output (all GDI commands can be recorded) of a progam into a EMF, view/edit the records and play it back any time, even with a world transformation.
Use 3d polygons instead of a 2d frame buffer? This would require considerable modification but only to the way that regions are computed; you can already put direct3d objects in a window with a polygonal region around the edges. One way or the other, you are still outputting to a 2d surface. And really, what is the point? Woo 3d icons.
Really, what is so broken about GDI that it needs to be replaced? IMO, there are far more important things to be overhauled in Windows than the video system. Rewriting a major component to provide eye candy should be a very low priority.
Another thing is that Avalon does not fill the same role as GDI does; Avalon also does what USER does and some shell stuff too. I'm saying that the important things in Avalon could be implemented using GDI.
But why is race a component?
Technically, race is completely arbitrary to anything important in a person.
Ideally, everyone would recognize that and never let it make a difference.
But in the real world, there is a connection between race and material perceptions.
For some reason, a person's race is an important part of their social identity; even though it is arbitrary. I think this may be partly because it is usually easy to identify someone by their race, just by their appearance. It's easy to create a stereotype associating the race to something since it is so easy to detect.
Take a group of people that are poor. The people in the community identify with each other; they favor members inside of the group over those outside. They all live near each other, since they favor the in-group. Their state of being poor has a great deal of momentum that cannot be easily changed: good education is requried for good income but the local schools have no money because the community is poor, higher education is difficult/impossible because no one can afford it, community services like police are weak and it contributes to crime and poor land value. Low land value further encourages the community to stay together because they cannot afford to move out. Social identity in the community is strong due to interdependence. People don't leave because 'abandoning' the community is stigmatized and members of the community are stigmatized. However, the strongest thing tying them together is easy identification of members of the community; even if that method is somethimes inaccurate, namely race.
If it was too hard to identify members of the in-group, the whole thing would fall apart. Other things like clothing, cars, houses, jewelery also serve to make identification easy. Also, members of more prosperous groups try to avoid being identified with the other group with expensive items the others can't afford.
Uniforms attempt to control identification by appearance: the military uses different uniforms and emblems to identify members by merit (rank). School uniforms try to mute the advantages of wealthy children by removing easy avenues to flaunt it with expensive clothing.
IMO, any attempt to create a relationship between something arbitrary (like race) to something material (like ability) is wrong. This includes positive connections: it always disgusts me to hear that I should have 'pride in my race' or whatever. What does race have to do with pride?
Any kind of group identification not completely and directly related to every member of a group creates arbitrary barriers between people. It's those barriers that should be attacked, along with momentum that creates and maintains bad conditions. How to implement it? I have no idea.