AFAIK, anti-spam methods tried to solve the problem on the email clients. But what about whitelists for email servers? Maybe something similar to the DNS system, with propagating server lists. So, you register your server with your telco, wait an hour or two, and the thing is propagated. Registration should be free, but a mandatory delay of at least 10 minutes between registration should be there; the telcos are also free to check if somebody is registering tons of servers (maybe a limit would do). This allows emailservers to reject unknown ones along with all their mail, so spammers could no longer setup a room full of machines sending millions of emails a day, and spambots with their own SMTP servers are useless. Furthermore, if some trojan hijacks Outlook accounts for spamming, email servers could (a) introduce an one second delay, thereby limiting the max amount of emails per day while not overly hurting the user, (b) report when a whitelist server suddenly sends heaps of data, and the sending server is obliged to investigate this and warn clients that they are sending too much.
All of this requires no client changes, they are all server side updates.
This does exist, but in a very limited fashion compared to what Vista and WDDM does and allows. Vista uses memory placement optimizations for existing 3D applications (DirectX and even OpenGL).
This means games don't have to be recoded to take advantage of the memory sharing architecture. A basic example, would be a low use texture that normally is shoved into the GPU because it needs to be in GPU RAM space for processing, so instead of it wasting high speed GPU RAM space, Vista will place in System RAM since there is no performance benefit, and yet the texture will appear to the application to be in the GPU and can have the GPU act on it as if it were internally loaded in GPU RAM Space. I by no means claim to be a 3D coding expert, but there are some really good true 'tech' articles on this subject at both MS and other sites like ATI and NVidia even.
Yes, it is possible to explicitly specify where the system shall allocate the resources. In D3D, you use the SYSTEMMEM pool, in OGL there are many ways. But there is also the fact that the *driver* can allocate system memory and use it as "normal" space for the resources if the videoram is full. This is a HUGE bottleneck in AGP systems because of the slow asynchronous transfer; XP aint optimized for this either. So, with Vista and PCI I see room for improved paging here.
DirectX has had a client/server model for a long time now, even on WindowsXP, running multiple instances of a 3D application in a Window is not a new thing, nor something only possible with OpenGL. (Remember MS was on big on OpenGL until they could not get the group to move to gaming hardware support concepts. Too bad the OpenGL of today and the willingness to adapt was not prevalent then, if so DirectX may never have existed.)
What is new is the way applications are 'multi-tasked', in a way the applications now think they have full access to the GPU and access to tons of GPU RAM, and Vista's WDDM instead is playing the 'multi-tasker' instead of the applications themselves realizing they are just a client and self yielding. Think of this as the change from the 286 to the 386, on the 286 multi-tasking was possible, but the application had to yield, on the 386 true pre-emptive multi-tasking was possible as the application didn't have a say, nor did the system care if it yielded or not.
Well, the D3D client/server model is decidedly different from the GL one. In D3D, I can use multiple d3d devices in one app, no problem there (very nice for modeling packages with multiple rendering windows, for example). Running two D3D apps side by side chokes my computer. Running one GL and one D3D app REALLY chokes my computer because two paths in the driver are trying to gain the upper hand. My guess is that Vista graphics drivers now play the role of a server and all apps are clients. Note that this is GL/D3D agnostic, so its no big deal to run them simultaneously anymore. This also makes multi-tasked apps really easy. But of course we get a nice possibility for more parallelization here. SLI etc. will make more sense with this.
I know OpenGL does have some strong arguments in the multi-client field, but with the WDDM and direction of technologies co-developed by MS/ATI/NVidia, this is not just about DirectX10 getting on the train, it is about laying new tracks for everyone to follow.
Again, I'm a not a 3D coding expert, but when people I know at ATI that I consider to be at the top of the game, have told me, 'holy shit', you will not believe the new areas we are heading with the technologies Vista and MS has brought to the table.
Yes, D3D10 (not DX10!) is reeeeally nice. It finally ditches all legacy stuff (no fixed function API baggage anymore), as a result the API is now quite lean and streamlined. Constant buffers are a nice idea as well as texture indices, superbuffers, geometry shaders, predicated geometry...
Unless the technical papers I have, have changed, then it is happening. This is why DirectX7 capable GPUs are used in
Funny. Many things you mention are actually old news for many graphics coders. Yes, these are nice new features to see in Windows, but hardly an overall breakthrough.
- The RAM thing exists already - without the paging. Drivers can allocate AGP- and even Sysram to get some space for the data. Sysmem is obviously a very bad idea with AGP, but its there. With PCI, this is much less of an issue. There the drivers can transfer from/to sysram, which gets paged by the OS already.
- Running multiple games at once will obviously hurt their FPS, unless they are not very demanding (running Gothic 3 and Oblivion at the same time is not a good idea). Running several 3D apps side by side HAS to work in Vista since the entire interface is going to be a 3D application, actually. In fact, D3D10 adopted a server/client model from OpenGL here; in OGL it never was a big deal to run several GL apps at once, because they are clients using one server (the graphics card).
- Accelerated drawing: not going to happen. At least not on a primitive stage. The windows are VERY likely to be rectangular textures, but forget about drawing every line with 3D, this is just too inefficient as it chokes the CPU because of wait states. 3D engines usually avoid as many API calls as possible for this reason. CorelDraw's calls are likely to involve GDI. It is perfectly ok for GDI to draw in the window texture. This is faster than traditional GDI because pre-Vista GDI immediately shows the result and has TONS of waitstates built in. The texture approach just involves some writing in a memory block. (Afaik this is the same way Qt4 handles drawing with GL-acceleration, and it is really MUCH faster than traditional 2D.)
- The composer: well, it is really strange why nobody EVER thought of this before. You don't even need a fully-featured composer, just some simple double-buffering would do. This is the very reason why tearing does not happen with Aero, NOT the blending and composing. Turn off double-buffering, and the tearing is back.
As for the vector thing, this DOES sound like marketing babble. I want this in a more detailed form. It would be very strange to see entire bitmaps transferred to the composer anyway, and I doubt its done this way now; heck, even X11 does not handle it this way.
Scaling old apps will give you a blurred result because of the bilinear filtering. Still better than having huge pixels though. GDI calls could be scaled nicely, yes, by sending the coordinates through a scale before drawing. But bitmaps will get blurry (that is, all icons etc.)
- User mode drivers are back, finally. But how am I going to handle GPU driver crashes in Vista? There is no textmode console, so what if video just doesnt restart?
I agree that Vista is a leap, but it just doesnt make it more attractive, really. Its expensive, has a bazillion features that need to be turned off etc. Direct3D 10 is going to be the likely reason why I'm gonna get it (its new features are VERY cool, and I write 3D graphics stuff), as soon as VistaAntiSpy is available:-) but other than that, hm.. The Samba guys have to play catch-up again, because MS changes the SMB protocol yet again and keeps the specs secret, thus enforcing lock-in again. So I can forget using my Samba fileserver with Vista, not good.
Then again, once OpenGL 3.0 is available, D3D10 won't be alone...
And thats right. It has no widgets, no GUI functionality AT ALL, so of course it CANNOT have any consistency. X does not care about widgets. X just handles graphics output. It is the layer BELOW the widgets. Why is this extremely simple fact so goddamn hard to understand?
-Any VB6 app. -Any.NET app. -Many small tools usually written with WinAPI directly, or with MFC. -In this regard, any MFC app. -Any wxWidgets based app (minus some custom wxWidget ones). -Any Qt based app (minus some custom Qt ones).
Most apps use the common dialog widgets, which belong to WinAPI. The core WinAPI widgets are unusable of course, but most apps I know of use the SAME filerequester, menus, treeviews/listviews, editor widget, IP editing widget, scrollbars, richtext editing field, tabwidgets, comboboxes, groupboxes, radio/check buttons, toolbars, sliders.... because the common dialog DLL has ALL of these. It exists since Windows 95. What it doesn't have is automatic layouting like Qt and GTK do. Its really just a bunch of widgets.
Implementing custom widgets is just damn easy in Windows, because the basic ones (also the common dialog ones) are so easy to tweak. This is actually a BAD thing, since in most cases people the custom widgets are UNNECESSARY. Most "tweaks" are about fancy looks (most of the time ending up as ugly widgets), extra functionality (confusing users), or some weird stuff thats just downright silly (for example, real-world metaphors commonly seen in media players with the volume knob).
There are some cases where you absolutely NEED tweaks. These include apps for very special operations (like controlling some machinery or doing CAT scans), or fields where custom interfaces are usual (like in media players or modeling packages).
Oh, and custom widgets are almost always tweaked WinAPI ones. It just doesn't pay off to write it from scratch.
How about actually READING what I wrote? I *said* that MS violate their own standards by using custom widgets in IE and others. So much for your "argument".
As for GTK-Qt, as another poster pointed out, it has its quirks. It also requires Qt, which may be a problem for some. Oh, and X still has no consistency because X has no widgets. You are mixing bananas and apples here. Learn to differentiate.
*Sigh*
Re:The myth of Windows GUI consistency.
on
Office 2007 UI License
·
· Score: 4, Informative
Well, obviously, X has *NO* consistency because it has no standard widgets. Windows has. WINAPI contains buttons, sliders, scrollbars, text edits, menus etc. So the *base* for consistency is there, which cannot be said for X.
But MS violate their own standards by creating custom widgets for Office and IE. This is something widely criticized by UI designers.
However, usually the WinAPI widgets are the core of Windows GUIs (tweaked buttons, menus...) Very little programs create their own widgets from the ground up. In X, Qt does everything from scratch, just like GTK, FOX, Athena, Motif, etc. The important thing is that their behaviour is not fully consistent. Aside from funny Office/IE widgets, I can reuse my knowledge with one Windows GUI when using another. Most Windows apps do NOT use custom widgets.
However, nowadays GTK and Qt have little custom quirks of this sort. Their differences are mostly optical (but it is a visual inconsistency when 90% of all apps are Qt/KDE-based and only one program uses GTK). However, the presence of two major TKs is a problem because distros tend to choose only one of these two. In this case you end up with a dependency that may be big enough to turn users and more importantly distro makers away (like "oh no, my system is purely GTK-based, I dont want Qt anywhere").
So what? Firefox is ONE - just ONE - project. And one of the biggest and well-known OS ones, with funding, corporate support etc. As is said in my previous posting, big opensource projects usually develop some sort of quality assurance. New code is reviewed, only core developers can actually commit to the repository etc. IE development pretty much stopped because of MS' ignorance. Firefox proves my point about availability, but does not prove that OS code is automatically better than CS one.
A good example is FMOD vs. Audiere/OpenAL/etc. There is absolutely no other sound library capable of what FMOD 4 does. Audiere is nice, but does not have 3D positional audio at all. OpenAL requires some vendor-specific (read: Creative Labs-specific) extensions for EAX. Other than that, no 3D audio. FMOD 4 can calculate 3D audio in *software* (although it does not sound as good as EAX hardware) and supports geometry obstruction (= close the door, and the TV running in the room is not as loud). Where can I find THIS in an opensource solution?
The solution to this is: the FMOD developer is VERY good, comes from the demo scene of the early 90s, and has tons of experience with software mixers, with actual optimizing, sound in general, and writing this library (it exists for several years now). As I said, good devs are NOT expendable. Which leads us to one keen insight our friend Ballmer had long ago: developers, developers, developers. They are everything. The question of code quality is not answered with OS/CS, its answered with the skills of the developer. Good devs produce good results, no matter if its CS or OS. The same goes for average/bad developers.
This is correct; many OS advocates believe Open Source automatically leads to better code. The truth is that most OS coders are just average. Many OS project members believe that when experienced guru X leaves the project, others will follow (or worse, they try to compensate the guru's absence with many average coders). Turns out the good devs are NOT expendable.
However, with Closed Source the situation really isnt any different. The only visible difference is that abandoned projects vanish, and do not reside in freshmeat/sourceforge/etc. But plenty of CS is *bad* code; just look at those ugly telco install CDs, many small shareware apps, many drivers (especially TV card ones)...
That said, big opensource projects usually develop some sort of quality assurance. New code is reviewed, only core developers can actually commit to the repository etc.
The clear OS advantages are security and availability. If I have 2 packages doing the same thing, one is OS, the other CS, then I usually choose the OS one, because I can examine it for buffer overflows, hidden trojans, backdoors etc. The CS package is a black box. (This is the main reason why OpenBSD opposes binary drivers.) Also, 3rd party patches are possible, which touches the second advantage: availability. If a CS software is abandoned, its *dead*. It won't be ported to succeeding platforms, it won't be patched etc. You have a binary copy, that's it. With OS, it is never really dead, you CAN port it (just look at the zillions of Doom ports), fork it, improve it, even if you are not the original developer. This is becoming more relevant in the future, when someone has to access very old files, but the format is unknown, and the only programs capable of reading it run only on machines that no longer exist. (NSA had to deal with this in the past.)
First, GPL have nothing to do at link time, it is only a distribution license.
This is a de-facto tautology. You can link any stuff you want, but it must not leave the house unless its legally ok. This is why distributions cannot be shipped with preinstalled nvidia closed source drivers, for example.
Second, linking with glibc have never made the resulting stuff (L)GPL.
In case of glibc, its LGPL. And linking with a LGPL lib is a gray area, because it does not clarify when the work is no longer derivative (remember, you use the glibc headers!). It gets even trickier in C++, where one derives from classes - then, it is totally unclear where to draw the line; is it derivative work when you derive from an abstract base class for custom I/O access (the typical "File" interface in C++ image loading libraries for example)? Remember, you have to present all this to judges - they do NOT see "common sense" in the different deriving practices (because, well, they aren't developers). So, it is absolutely logical for you and me that such a case is *not* derivative work, but not for the judge.
This is one reason why Mozilla has its MPL, Sun its CDDL. If a LGPL v3 would clarify the headers and class deriving situation, things would get easier. (If the LGPL v3 became more strict, for example regarding *every* class derivation as derivative work, there would be a need for another license though; MPL and CDDL have their issues, unfortunately.)
But GPL libraries fully endorse the viral nature and require the result to be GPLed, or at least put under a GPL-compatible license / dual license. This is why usually GPL for libraries makes no sense; XviD is a special case, they cannot distribute it in binary form, because this would violate MPEG4 terms, so it is distributed as source only. Since any closed-source app linking with XviD would violate the terms too, it makes sense to put it under GPL. Other than that, LGPL / MPL / BSD - like licenses are the way to go for libraries.
Great. So linking an app in Linux will be only possible a) if the app is GPLed b) manually links to another libc. If there is one library that shows why lgpl is a good idea, then its glibc.
I don't feel that plugins give as good of an experience as native browser controls.
Technically, the difference should be zero, else something is very wrong. Take Safari/Konqueror for instance; *everything* is handled by plugins, right down to simple images.
Plugins really are just elements like anything else, they are just loaded at run-time and not linked statically into the browser. Thats all.
As for your OOP questions, yes it is a problem that code and data is mixed, but at least things are divided up as objects. Procedural programming tends to be very messy, not organizing anything anywhere (and lets face it, inheritance, abstract base clases etc. are *very* nice - good luck writing the additional code for similar functionality in pure C). Generic progrmaming separates data and code, but is harder to code (also, at least in C++ its compile-time only; for run-time data/code binding, you need dynamic types).
Also, when you have only one code for one type of data, OOP is not problematic. For example, a "Window" class contains the only code that actually manages system windows (also, here we have a common use of abstract interface classes for cross-platform support; write a derived class for Win32, one for OSX, one for X11... in C you have to deal with function pointers, good luck with that). It is a wholly different thing than linked lists, for example, where you *do* want to separate data from code.
Its a pity that Objective-C didn't win the C successor race. While its syntax sucks hard, its way of handling objects is much more flexible.
Sure there are time and money issues which you have to balance with all your other budgetary constraints.
Exactly. The result is almost always: "use D3D". Less time-consuming, less demanding -> costs less -> most companies choose D3D, with OpenGL becoming a rather exotic option.
About the middle-mouse thing, yes, it makes sense. However, it still gets mixed. For example, it is *impossible* to copy & paste contents from a terminal in a sane way except using middle-mouse. Middle-mouse copying is sometimes useful, but I'd rather vote for removing it from text operations and leave it at other levels. It is just too confusing with text.
3. Just because of a context parameter? Sounds like a trivial problem to me. Simply accept a context argument in your helper library calls, and you are done. Having to specify the context everywhere is not wise of course. Win32 has a more sane approach (yes, WinAPI and more sane can be together). The application has a HINSTANCE, and the window has a HWND handle. Upon window creation, the HINSTANCE is an argument for CreateWindow(). Afterwards, the HWND is specified when calling window functions, nothing more. This would translate to X11 only requiring Window parameters. The context should be bound to the process, like some OpenGL implementations do.
4. This is nice of course, but keep in mind that it is very hardware-acceleration-unfriendly. For HW accel, you need some mutex access to the image resource in VRAM. The 3D APIs approach would be wise here: create an image, with a SIMPLE bit format specification (like R8G8B8 or R5G6B5), then call some lock() / map() function that maps the image memory block to an address range in the local address space, and there you go, simply access the image just like one in memory (here you can upload a pic for example). Afterwards, call unmap() / unlock(). In essence, this just adds a couple more lines to your image in memory.
5. Now this is something I 100% disagree. Window management is NOT the bottleneck. SW-side compositing is. The bloated an inefficient XAA architecture was. With AIGLX, the hardware does compositing directly. EXT_texture_from_pixmap makes sure the pixmap used for compositing is sitting in vidmem as a texture, so that compositing does not involve an additional image transfer. And, users are confused by UI they do not understand.
Consistency IS a good thing. Imagine that buttons would behave wildly different in each application (I actually experienced this in the Amiga/Atari days). If a small rectangle on the border enlarges the window in one app, and closes it in another, this just begs for confusion. Media players are a prime example of how to design bad UIs. People here are regularly lost in the Windows Media Player because this ugly thing looks absolutely bizarre in Windows. The only thing most people understand are the basic playback buttons (stop, pause, play).... and guess what, their symbols are consistent with the standard player button symbols!
6. Here I partially agree. This communication is actually possible, just see xfterm4 for example; it will refuse to fully enlarge because it wants the size to be a multiple of the font glyph dimensions, so that there are no partially hidden letters. However, communication is still shaky. The proposal for a background erasing control I wrote before is a good example of how to solve a tricky problem easily with just a little more communication. It actually is the way Windows does it.
In Windows, the WM_ERASEBKGND is sent to a window when it is about to be erased (that is, its region will be filled with the background color). The usual reaction to this message is "erase". You can intercept it and send "do not erase" instead. Additionally, you can catch button press messages (WM_NC*** messages I guess). If you send "no hit", the message will be passed to the next window below.
Now, these two messages allow arbitrary shapes: upon WM_ERASEBKGND, send "do not erase". WM_PAINT paints the window. WM_NC*** causes the app to look up in a bitmask to see if the clicked pixel actually belongs to the window (the NC*** messages will be sent when the click happens in the window region, which is always rectangular). In the bitmask, if the matching entry is a 0, then there is nothing painted -> send "no hit".
Of course it does. You propose usage of multiple libraries as a pendant to the DirectX SDK, and I commented your points about it. Now I suggest YOU read my points and give me an actual reply. So far you didn't prove anything wrong.
Why would anyone port something to Linux? There is no market there. "Cross-platform" means "consoles & Windows" for game developers. Oh, and your "relinking" is not as simple as you think. You have to rebuild the entire project.
So the entirety of DirectX is significantly easier to learn, and the APIs and interfaces are all consistent and work flawlessly?
Yes. MUCH easier than OpenGL for advanced effects (like ambient occlusion). DirectInput kicks ass; where is the Linux equivalent? OIS is the next best thing, covers about 1/4th of DI's functionality, and is hard to discover (I stumbled upon it by accident). And while DirectShow is a PITA, it is still easier to use than some Linux video playback library (libtheora means a LOT of work, libavcodec is just a thing from another world, Gstreamer needs the correct codecs and lacks a good documentation).
And it's Free and cross-platform?
This is absolutely IRRELEVANT for game development. Game development is about MONEY. AAA games need a system that does not stand in the way and takes too much time to learn - because time is money. "Free" has absolutely zero relevance there. If a kit costs $1000, but cuts development time to 1/3rd, it will be bought by the companies. This is why game developers usually choose FMOD over OpenAL or Audiere (aside from the fact that FMOD 4 has so many features the other two don't even remotely provide). Cross-Platform is irrelevant for AAA games as well; AAA means tons of effects. Porting it to the console absolutely requires additional work. You do NOT want the extra overhead from the cross-platform layer on a PS2, for example.
Also, good job counting all the libraries I listed. PROTIP: you only need (at most) one from each category.
Most have little to no documentation, are not thoroughly tested in non-Unix environments, have no VisualC workspaces (don't even think of using autotools in Windows), have APIs with exactly zero similarities, and at best a few samples. Yeah.
Obviously you are not experienced in hardware 3D graphics programming. It is at times MUCH harder to accomplish the same effect in OpenGL than in D3D. Before 2005, there wasnt even a decent render-to-texture extension available, just pbuffers (and they suck hard). D3D had them since 1998. Shaders? Before GLSL was finally out, there were about 6 vendor-specific ones. Do you really believe that game developers have the TIME to implement and test so many code paths? Carmack has the luxury of spending time with this, but most other game developers don't. Resources for OGL are scattered across the net; in D3D, you have one big, detailed programmers guide and reference, along with over 30 examples covering a lot of state-of-the-art effects. In D3D, I have examples for PRT, instancing, subsurface scattering, motion blur etc. Where is the kickass OpenGL SDK offering me this? NeHe covers just the basics. 99% of all OpenGL sites recycle the basics over and over. Its extremely hard to write a state-of-the-art engine with OGL, it is much easier with D3D. OpenGL 3.0 is likely to change this, but until then, we have to fiddle with a severe lack of resources and many fallbacks for different OpenGL architectures.
Without them, there is zero chance of gaming. At all. They are the failings? Explain this. Without NVidia, I have zero chance of getting Doom 3 and UT2004 to work in Linux. Absolutely ZERO.
In general, X is *NOT* the problem. With AIGLX, Composite and Render X has the necessary extensions to be a match for both OSX and Vista. Of course there are things that need to be cleaned up (most notably the fonts issue; X has TWO font systems, with one being a legacy one). But *replacing* it is likely to end up in a stalled project (like the other 513573 X successors out there).
Instead, I opt for improving X: * Clean up the font system as I mentioned before * Clean up the API * Kick support for obscure drivers and displays * Do not include Athena by default * Provide window managing extensions for giving the app control over the canvas filling, thus allowing binary-transparent windows (quite easy actually: simply suppress the call that fills the canvas with the default background color, and draw the contents with the alpha mask, 0 for don't-draw-the-pixel, 1 for draw-the-pixel; also, give the app the possibility to intercept mouse clicks, so that the message can be passed through if the click was on a 0-pixel) * Kick XAA etc. EXA is a much nicer acceleration architecture * ONE (!!!) clipboard for *everything* (both Unix-style middle-mouse click and Windows-style Ctrl+C Ctrl+V) * A better xorg.conf configuration tool * Improved Xinerama support for displays of different size * Support for moving windows across X server screens
We have two groups: the free software advocates and the pro-desktoplinux crowd. They are NOT the same. Here's why:
The free software advocates want everything to be opensource and 100% free. A fully functional desktoplinux with support for latest state-of-the-art hardware is of less to no concern for them. Their goal is a 100% free system with zero propietary components.
The desktoplinux crowd is much more pragmatic, and doesn't care if the graphics drivers are binary and propietary. Their goal is a competitor to Windows and reclaiming the desktop, ending the MS monopoly over it (which gives MS the power to establish their standards easily).
Both actually have similar goals: the former want a free system, the latter want a free desktop. But their goals are in conflict with each other.
The problem is that Gnome and KDE have both have their own architectures. For example, KDE has kioslaves, Gnome has gnomevfs. Now, if you mount a share via gnomevfs, all Gnome apps can access it - and NO ONE ELSE. In Windows, ALL apps can use UNC paths (\\\\), ALL apps use the same file requester (except some 16-bit ones) etc.
Additionally, the Windows UI is generally more responsive than Gtk ones; Qt is pretty fast, but Gtk UIs tend to behave like slugs. Thunderbird or Evolution, for example, and trying to scroll through 800 emails, the emails list redraws itself so slowly that scrolling becomes an exercise in patience; in Windows, I can scroll smoothly. This seems to be because of very slow font rendering (I had the same scrolling problem when viewing the email contents, until I switched the font to Terminus; unfortunately, it seems to be impossible to use Terminus in the emails list).
Window redrawing, moving etc. works extremely well with AIGLX, but when the windows get resized, and the toolkit kicks in, things suddenly repaint slow as if everything gets repainted by putpixel() calls. And yes, this CAN be improved. Look at e17; they can repaint the WHOLE DAMN SCREEN and it is a thounsand times faster than Gtk, mainly because they do it much smarter and retain the drawcalls until a final flush is invoked, thus giving the system the chance to clip partially visible and kick out invisible and duplicate elements. Additionally, blending can be done correctly without worrying about the correct order in the app (the system takes care of the final sorting). In contrast, Gtk paints immediately, thus giving away the chance of said optimizations.
So, while WMP7+ is horrid, horrid software, I wouldn't say that the clear winner on Windows is a Free alternative.
It is: search for Media Player Classic, Real Alternative, Quicktime Alternative. Media Player Classic is an excellent player in an improved WMP6-style. Very responsive, slick interface, extensive functionality. Real & Quicktime Alternative are MPC-backends for playing Real/Quicktime streams *without* the need for Real and/or Quicktime player. These backends do not play all rm/mov files, but most.
Now, if MS would design the WMP UI like the one in MPC, WMP would be an option again.
Slashdot Mirror
AFAIK, anti-spam methods tried to solve the problem on the email clients.
But what about whitelists for email servers? Maybe something similar to the DNS system, with propagating server lists. So, you register your server with your telco, wait an hour or two, and the thing is propagated. Registration should be free, but a mandatory delay of at least 10 minutes between registration should be there; the telcos are also free to check if somebody is registering tons of servers (maybe a limit would do). This allows emailservers to reject unknown ones along with all their mail, so spammers could no longer setup a room full of machines sending millions of emails a day, and spambots with their own SMTP servers are useless. Furthermore, if some trojan hijacks Outlook accounts for spamming, email servers could (a) introduce an one second delay, thereby limiting the max amount of emails per day while not overly hurting the user, (b) report when a whitelist server suddenly sends heaps of data, and the sending server is obliged to investigate this and warn clients that they are sending too much.
All of this requires no client changes, they are all server side updates.
This does exist, but in a very limited fashion compared to what Vista and WDDM does and allows. Vista uses memory placement optimizations for existing 3D applications (DirectX and even OpenGL).
This means games don't have to be recoded to take advantage of the memory sharing architecture. A basic example, would be a low use texture that normally is shoved into the GPU because it needs to be in GPU RAM space for processing, so instead of it wasting high speed GPU RAM space, Vista will place in System RAM since there is no performance benefit, and yet the texture will appear to the application to be in the GPU and can have the GPU act on it as if it were internally loaded in GPU RAM Space.
I by no means claim to be a 3D coding expert, but there are some really good true 'tech' articles on this subject at both MS and other sites like ATI and NVidia even.
Yes, it is possible to explicitly specify where the system shall allocate the resources. In D3D, you use the SYSTEMMEM pool, in OGL there are many ways.
But there is also the fact that the *driver* can allocate system memory and use it as "normal" space for the resources if the videoram is full. This is a HUGE bottleneck in AGP systems because of the slow asynchronous transfer; XP aint optimized for this either. So, with Vista and PCI I see room for improved paging here.
DirectX has had a client/server model for a long time now, even on WindowsXP, running multiple instances of a 3D application in a Window is not a new thing, nor something only possible with OpenGL. (Remember MS was on big on OpenGL until they could not get the group to move to gaming hardware support concepts. Too bad the OpenGL of today and the willingness to adapt was not prevalent then, if so DirectX may never have existed.)
What is new is the way applications are 'multi-tasked', in a way the applications now think they have full access to the GPU and access to tons of GPU RAM, and Vista's WDDM instead is playing the 'multi-tasker' instead of the applications themselves realizing they are just a client and self yielding. Think of this as the change from the 286 to the 386, on the 286 multi-tasking was possible, but the application had to yield, on the 386 true pre-emptive multi-tasking was possible as the application didn't have a say, nor did the system care if it yielded or not.
Well, the D3D client/server model is decidedly different from the GL one. In D3D, I can use multiple d3d devices in one app, no problem there (very nice for modeling packages with multiple rendering windows, for example). Running two D3D apps side by side chokes my computer. Running one GL and one D3D app REALLY chokes my computer because two paths in the driver are trying to gain the upper hand. My guess is that Vista graphics drivers now play the role of a server and all apps are clients. Note that this is GL/D3D agnostic, so its no big deal to run them simultaneously anymore. This also makes multi-tasked apps really easy. But of course we get a nice possibility for more parallelization here. SLI etc. will make more sense with this.
I know OpenGL does have some strong arguments in the multi-client field, but with the WDDM and direction of technologies co-developed by MS/ATI/NVidia, this is not just about DirectX10 getting on the train, it is about laying new tracks for everyone to follow.
Again, I'm a not a 3D coding expert, but when people I know at ATI that I consider to be at the top of the game, have told me, 'holy shit', you will not believe the new areas we are heading with the technologies Vista and MS has brought to the table.
Yes, D3D10 (not DX10!) is reeeeally nice. It finally ditches all legacy stuff (no fixed function API baggage anymore), as a result the API is now quite lean and streamlined. Constant buffers are a nice idea as well as texture indices, superbuffers, geometry shaders, predicated geometry...
Unless the technical papers I have, have changed, then it is happening. This is why DirectX7 capable GPUs are used in
Funny. Many things you mention are actually old news for many graphics coders. Yes, these are nice new features to see in Windows, but hardly an overall breakthrough.
:-) but other than that, hm.. The Samba guys have to play catch-up again, because MS changes the SMB protocol yet again and keeps the specs secret, thus enforcing lock-in again. So I can forget using my Samba fileserver with Vista, not good.
- The RAM thing exists already - without the paging. Drivers can allocate AGP- and even Sysram to get some space for the data. Sysmem is obviously a very bad idea with AGP, but its there. With PCI, this is much less of an issue. There the drivers can transfer from/to sysram, which gets paged by the OS already.
- Running multiple games at once will obviously hurt their FPS, unless they are not very demanding (running Gothic 3 and Oblivion at the same time is not a good idea). Running several 3D apps side by side HAS to work in Vista since the entire interface is going to be a 3D application, actually. In fact, D3D10 adopted a server/client model from OpenGL here; in OGL it never was a big deal to run several GL apps at once, because they are clients using one server (the graphics card).
- Accelerated drawing: not going to happen. At least not on a primitive stage. The windows are VERY likely to be rectangular textures, but forget about drawing every line with 3D, this is just too inefficient as it chokes the CPU because of wait states. 3D engines usually avoid as many API calls as possible for this reason. CorelDraw's calls are likely to involve GDI. It is perfectly ok for GDI to draw in the window texture. This is faster than traditional GDI because pre-Vista GDI immediately shows the result and has TONS of waitstates built in. The texture approach just involves some writing in a memory block. (Afaik this is the same way Qt4 handles drawing with GL-acceleration, and it is really MUCH faster than traditional 2D.)
- The composer: well, it is really strange why nobody EVER thought of this before. You don't even need a fully-featured composer, just some simple double-buffering would do. This is the very reason why tearing does not happen with Aero, NOT the blending and composing. Turn off double-buffering, and the tearing is back.
As for the vector thing, this DOES sound like marketing babble. I want this in a more detailed form. It would be very strange to see entire bitmaps transferred to the composer anyway, and I doubt its done this way now; heck, even X11 does not handle it this way.
Scaling old apps will give you a blurred result because of the bilinear filtering. Still better than having huge pixels though. GDI calls could be scaled nicely, yes, by sending the coordinates through a scale before drawing. But bitmaps will get blurry (that is, all icons etc.)
- User mode drivers are back, finally. But how am I going to handle GPU driver crashes in Vista? There is no textmode console, so what if video just doesnt restart?
I agree that Vista is a leap, but it just doesnt make it more attractive, really. Its expensive, has a bazillion features that need to be turned off etc. Direct3D 10 is going to be the likely reason why I'm gonna get it (its new features are VERY cool, and I write 3D graphics stuff), as soon as VistaAntiSpy is available
Then again, once OpenGL 3.0 is available, D3D10 won't be alone...
And thats right. It has no widgets, no GUI functionality AT ALL, so of course it CANNOT have any consistency.
X does not care about widgets. X just handles graphics output. It is the layer BELOW the widgets.
Why is this extremely simple fact so goddamn hard to understand?
Hmm lets see.
.NET app.
-Any VB6 app.
-Any
-Many small tools usually written with WinAPI directly, or with MFC.
-In this regard, any MFC app.
-Any wxWidgets based app (minus some custom wxWidget ones).
-Any Qt based app (minus some custom Qt ones).
Most apps use the common dialog widgets, which belong to WinAPI. The core WinAPI widgets are unusable of course, but most apps I know of use the SAME filerequester, menus, treeviews/listviews, editor widget, IP editing widget, scrollbars, richtext editing field, tabwidgets, comboboxes, groupboxes, radio/check buttons, toolbars, sliders.... because the common dialog DLL has ALL of these. It exists since Windows 95. What it doesn't have is automatic layouting like Qt and GTK do. Its really just a bunch of widgets.
Implementing custom widgets is just damn easy in Windows, because the basic ones (also the common dialog ones) are so easy to tweak. This is actually a BAD thing, since in most cases people the custom widgets are UNNECESSARY. Most "tweaks" are about fancy looks (most of the time ending up as ugly widgets), extra functionality (confusing users), or some weird stuff thats just downright silly (for example, real-world metaphors commonly seen in media players with the volume knob).
There are some cases where you absolutely NEED tweaks. These include apps for very special operations (like controlling some machinery or doing CAT scans), or fields where custom interfaces are usual (like in media players or modeling packages).
Oh, and custom widgets are almost always tweaked WinAPI ones. It just doesn't pay off to write it from scratch.
How about actually READING what I wrote? I *said* that MS violate their own standards by using custom widgets in IE and others. So much for your "argument".
As for GTK-Qt, as another poster pointed out, it has its quirks. It also requires Qt, which may be a problem for some. Oh, and X still has no consistency because X has no widgets. You are mixing bananas and apples here. Learn to differentiate.
*Sigh*
Well, obviously, X has *NO* consistency because it has no standard widgets. Windows has. WINAPI contains buttons, sliders, scrollbars, text edits, menus etc. So the *base* for consistency is there, which cannot be said for X.
...) Very little programs create their own widgets from the ground up. In X, Qt does everything from scratch, just like GTK, FOX, Athena, Motif, etc. The important thing is that their behaviour is not fully consistent. Aside from funny Office/IE widgets, I can reuse my knowledge with one Windows GUI when using another. Most Windows apps do NOT use custom widgets.
But MS violate their own standards by creating custom widgets for Office and IE. This is something widely criticized by UI designers.
However, usually the WinAPI widgets are the core of Windows GUIs (tweaked buttons, menus
However, nowadays GTK and Qt have little custom quirks of this sort. Their differences are mostly optical (but it is a visual inconsistency when 90% of all apps are Qt/KDE-based and only one program uses GTK). However, the presence of two major TKs is a problem because distros tend to choose only one of these two. In this case you end up with a dependency that may be big enough to turn users and more importantly distro makers away (like "oh no, my system is purely GTK-based, I dont want Qt anywhere").
In short:
We need to stop mixing web *applications* with web *documents*.
Things like Horde or Plesk are perfectly OK as webapps, but not with web document technology (HTML/CSS/Javascript).
So what? Firefox is ONE - just ONE - project. And one of the biggest and well-known OS ones, with funding, corporate support etc. As is said in my previous posting, big opensource projects usually develop some sort of quality assurance. New code is reviewed, only core developers can actually commit to the repository etc. IE development pretty much stopped because of MS' ignorance. Firefox proves my point about availability, but does not prove that OS code is automatically better than CS one.
A good example is FMOD vs. Audiere/OpenAL/etc. There is absolutely no other sound library capable of what FMOD 4 does. Audiere is nice, but does not have 3D positional audio at all. OpenAL requires some vendor-specific (read: Creative Labs-specific) extensions for EAX. Other than that, no 3D audio. FMOD 4 can calculate 3D audio in *software* (although it does not sound as good as EAX hardware) and supports geometry obstruction (= close the door, and the TV running in the room is not as loud). Where can I find THIS in an opensource solution?
The solution to this is: the FMOD developer is VERY good, comes from the demo scene of the early 90s, and has tons of experience with software mixers, with actual optimizing, sound in general, and writing this library (it exists for several years now). As I said, good devs are NOT expendable. Which leads us to one keen insight our friend Ballmer had long ago: developers, developers, developers. They are everything. The question of code quality is not answered with OS/CS, its answered with the skills of the developer. Good devs produce good results, no matter if its CS or OS. The same goes for average/bad developers.
This is correct; many OS advocates believe Open Source automatically leads to better code. The truth is that most OS coders are just average. Many OS project members believe that when experienced guru X leaves the project, others will follow (or worse, they try to compensate the guru's absence with many average coders). Turns out the good devs are NOT expendable.
However, with Closed Source the situation really isnt any different. The only visible difference is that abandoned projects vanish, and do not reside in freshmeat/sourceforge/etc. But plenty of CS is *bad* code; just look at those ugly telco install CDs, many small shareware apps, many drivers (especially TV card ones)...
That said, big opensource projects usually develop some sort of quality assurance. New code is reviewed, only core developers can actually commit to the repository etc.
The clear OS advantages are security and availability. If I have 2 packages doing the same thing, one is OS, the other CS, then I usually choose the OS one, because I can examine it for buffer overflows, hidden trojans, backdoors etc. The CS package is a black box. (This is the main reason why OpenBSD opposes binary drivers.) Also, 3rd party patches are possible, which touches the second advantage: availability. If a CS software is abandoned, its *dead*. It won't be ported to succeeding platforms, it won't be patched etc. You have a binary copy, that's it. With OS, it is never really dead, you CAN port it (just look at the zillions of Doom ports), fork it, improve it, even if you are not the original developer. This is becoming more relevant in the future, when someone has to access very old files, but the format is unknown, and the only programs capable of reading it run only on machines that no longer exist. (NSA had to deal with this in the past.)
First, GPL have nothing to do at link time, it is only a distribution license.
This is a de-facto tautology. You can link any stuff you want, but it must not leave the house unless its legally ok. This is why distributions cannot be shipped with preinstalled nvidia closed source drivers, for example.
Second, linking with glibc have never made the resulting stuff (L)GPL.
In case of glibc, its LGPL. And linking with a LGPL lib is a gray area, because it does not clarify when the work is no longer derivative (remember, you use the glibc headers!). It gets even trickier in C++, where one derives from classes - then, it is totally unclear where to draw the line; is it derivative work when you derive from an abstract base class for custom I/O access (the typical "File" interface in C++ image loading libraries for example)? Remember, you have to present all this to judges - they do NOT see "common sense" in the different deriving practices (because, well, they aren't developers). So, it is absolutely logical for you and me that such a case is *not* derivative work, but not for the judge.
This is one reason why Mozilla has its MPL, Sun its CDDL. If a LGPL v3 would clarify the headers and class deriving situation, things would get easier. (If the LGPL v3 became more strict, for example regarding *every* class derivation as derivative work, there would be a need for another license though; MPL and CDDL have their issues, unfortunately.)
But GPL libraries fully endorse the viral nature and require the result to be GPLed, or at least put under a GPL-compatible license / dual license. This is why usually GPL for libraries makes no sense; XviD is a special case, they cannot distribute it in binary form, because this would violate MPEG4 terms, so it is distributed as source only. Since any closed-source app linking with XviD would violate the terms too, it makes sense to put it under GPL. Other than that, LGPL / MPL / BSD - like licenses are the way to go for libraries.
important stuff like the C library
Great. So linking an app in Linux will be only possible a) if the app is GPLed b) manually links to another libc.
If there is one library that shows why lgpl is a good idea, then its glibc.
I don't feel that plugins give as good of an experience as native browser controls.
Technically, the difference should be zero, else something is very wrong. Take Safari/Konqueror for instance; *everything* is handled by plugins, right down to simple images.
Plugins really are just elements like anything else, they are just loaded at run-time and not linked statically into the browser. Thats all.
As for your OOP questions, yes it is a problem that code and data is mixed, but at least things are divided up as objects. Procedural programming tends to be very messy, not organizing anything anywhere (and lets face it, inheritance, abstract base clases etc. are *very* nice - good luck writing the additional code for similar functionality in pure C). Generic progrmaming separates data and code, but is harder to code (also, at least in C++ its compile-time only; for run-time data/code binding, you need dynamic types).
Also, when you have only one code for one type of data, OOP is not problematic. For example, a "Window" class contains the only code that actually manages system windows (also, here we have a common use of abstract interface classes for cross-platform support; write a derived class for Win32, one for OSX, one for X11... in C you have to deal with function pointers, good luck with that). It is a wholly different thing than linked lists, for example, where you *do* want to separate data from code.
Its a pity that Objective-C didn't win the C successor race. While its syntax sucks hard, its way of handling objects is much more flexible.
Sure there are time and money issues which you have to balance with all your other budgetary constraints.
Exactly. The result is almost always: "use D3D". Less time-consuming, less demanding -> costs less -> most companies choose D3D, with OpenGL becoming a rather exotic option.
About the middle-mouse thing, yes, it makes sense. However, it still gets mixed. For example, it is *impossible* to copy & paste contents from a terminal in a sane way except using middle-mouse. Middle-mouse copying is sometimes useful, but I'd rather vote for removing it from text operations and leave it at other levels. It is just too confusing with text.
.... and guess what, their symbols are consistent with the standard player button symbols!
3. Just because of a context parameter? Sounds like a trivial problem to me. Simply accept a context argument in your helper library calls, and you are done. Having to specify the context everywhere is not wise of course. Win32 has a more sane approach (yes, WinAPI and more sane can be together). The application has a HINSTANCE, and the window has a HWND handle. Upon window creation, the HINSTANCE is an argument for CreateWindow(). Afterwards, the HWND is specified when calling window functions, nothing more. This would translate to X11 only requiring Window parameters. The context should be bound to the process, like some OpenGL implementations do.
4. This is nice of course, but keep in mind that it is very hardware-acceleration-unfriendly. For HW accel, you need some mutex access to the image resource in VRAM. The 3D APIs approach would be wise here: create an image, with a SIMPLE bit format specification (like R8G8B8 or R5G6B5), then call some lock() / map() function that maps the image memory block to an address range in the local address space, and there you go, simply access the image just like one in memory (here you can upload a pic for example). Afterwards, call unmap() / unlock(). In essence, this just adds a couple more lines to your image in memory.
5. Now this is something I 100% disagree. Window management is NOT the bottleneck. SW-side compositing is. The bloated an inefficient XAA architecture was. With AIGLX, the hardware does compositing directly. EXT_texture_from_pixmap makes sure the pixmap used for compositing is sitting in vidmem as a texture, so that compositing does not involve an additional image transfer. And, users are confused by UI they do not understand.
Consistency IS a good thing. Imagine that buttons would behave wildly different in each application (I actually experienced this in the Amiga/Atari days). If a small rectangle on the border enlarges the window in one app, and closes it in another, this just begs for confusion. Media players are a prime example of how to design bad UIs. People here are regularly lost in the Windows Media Player because this ugly thing looks absolutely bizarre in Windows. The only thing most people understand are the basic playback buttons (stop, pause, play)
6. Here I partially agree. This communication is actually possible, just see xfterm4 for example; it will refuse to fully enlarge because it wants the size to be a multiple of the font glyph dimensions, so that there are no partially hidden letters. However, communication is still shaky. The proposal for a background erasing control I wrote before is a good example of how to solve a tricky problem easily with just a little more communication. It actually is the way Windows does it.
In Windows, the WM_ERASEBKGND is sent to a window when it is about to be erased (that is, its region will be filled with the background color). The usual reaction to this message is "erase". You can intercept it and send "do not erase" instead. Additionally, you can catch button press messages (WM_NC*** messages I guess). If you send "no hit", the message will be passed to the next window below.
Now, these two messages allow arbitrary shapes: upon WM_ERASEBKGND, send "do not erase". WM_PAINT paints the window. WM_NC*** causes the app to look up in a bitmask to see if the clicked pixel actually belongs to the window (the NC*** messages will be sent when the click happens in the window region, which is always rectangular). In the bitmask, if the matching entry is a 0, then there is nothing painted -> send "no hit".
Of course it does. You propose usage of multiple libraries as a pendant to the DirectX SDK, and I commented your points about it. Now I suggest YOU read my points and give me an actual reply. So far you didn't prove anything wrong.
Why would anyone port something to Linux? There is no market there. "Cross-platform" means "consoles & Windows" for game developers. Oh, and your "relinking" is not as simple as you think. You have to rebuild the entire project.
So the entirety of DirectX is significantly easier to learn, and the APIs and interfaces are all consistent and work flawlessly?
Yes. MUCH easier than OpenGL for advanced effects (like ambient occlusion). DirectInput kicks ass; where is the Linux equivalent? OIS is the next best thing, covers about 1/4th of DI's functionality, and is hard to discover (I stumbled upon it by accident). And while DirectShow is a PITA, it is still easier to use than some Linux video playback library (libtheora means a LOT of work, libavcodec is just a thing from another world, Gstreamer needs the correct codecs and lacks a good documentation).
And it's Free and cross-platform?
This is absolutely IRRELEVANT for game development. Game development is about MONEY. AAA games need a system that does not stand in the way and takes too much time to learn - because time is money. "Free" has absolutely zero relevance there. If a kit costs $1000, but cuts development time to 1/3rd, it will be bought by the companies. This is why game developers usually choose FMOD over OpenAL or Audiere (aside from the fact that FMOD 4 has so many features the other two don't even remotely provide). Cross-Platform is irrelevant for AAA games as well; AAA means tons of effects. Porting it to the console absolutely requires additional work. You do NOT want the extra overhead from the cross-platform layer on a PS2, for example.
Also, good job counting all the libraries I listed. PROTIP: you only need (at most) one from each category.
Most have little to no documentation, are not thoroughly tested in non-Unix environments, have no VisualC workspaces (don't even think of using autotools in Windows), have APIs with exactly zero similarities, and at best a few samples. Yeah.
Obviously you are not experienced in hardware 3D graphics programming. It is at times MUCH harder to accomplish the same effect in OpenGL than in D3D. Before 2005, there wasnt even a decent render-to-texture extension available, just pbuffers (and they suck hard). D3D had them since 1998. Shaders? Before GLSL was finally out, there were about 6 vendor-specific ones. Do you really believe that game developers have the TIME to implement and test so many code paths? Carmack has the luxury of spending time with this, but most other game developers don't. Resources for OGL are scattered across the net; in D3D, you have one big, detailed programmers guide and reference, along with over 30 examples covering a lot of state-of-the-art effects. In D3D, I have examples for PRT, instancing, subsurface scattering, motion blur etc. Where is the kickass OpenGL SDK offering me this? NeHe covers just the basics. 99% of all OpenGL sites recycle the basics over and over. Its extremely hard to write a state-of-the-art engine with OGL, it is much easier with D3D. OpenGL 3.0 is likely to change this, but until then, we have to fiddle with a severe lack of resources and many fallbacks for different OpenGL architectures.
Without them, there is zero chance of gaming. At all. They are the failings? Explain this. Without NVidia, I have zero chance of getting Doom 3 and UT2004 to work in Linux. Absolutely ZERO.
In general, X is *NOT* the problem. With AIGLX, Composite and Render X has the necessary extensions to be a match for both OSX and Vista. Of course there are things that need to be cleaned up (most notably the fonts issue; X has TWO font systems, with one being a legacy one). But *replacing* it is likely to end up in a stalled project (like the other 513573 X successors out there).
Instead, I opt for improving X:
* Clean up the font system as I mentioned before
* Clean up the API
* Kick support for obscure drivers and displays
* Do not include Athena by default
* Provide window managing extensions for giving the app control over the canvas filling, thus allowing binary-transparent windows
(quite easy actually: simply suppress the call that fills the canvas with the default background color, and draw the contents with the alpha mask, 0 for don't-draw-the-pixel, 1 for draw-the-pixel; also, give the app the possibility to intercept mouse clicks, so that the message can be passed through if the click was on a 0-pixel)
* Kick XAA etc. EXA is a much nicer acceleration architecture
* ONE (!!!) clipboard for *everything* (both Unix-style middle-mouse click and Windows-style Ctrl+C Ctrl+V)
* A better xorg.conf configuration tool
* Improved Xinerama support for displays of different size
* Support for moving windows across X server screens
We have two groups: the free software advocates and the pro-desktoplinux crowd. They are NOT the same. Here's why:
The free software advocates want everything to be opensource and 100% free. A fully functional desktoplinux with support for latest state-of-the-art hardware is of less to no concern for them. Their goal is a 100% free system with zero propietary components.
The desktoplinux crowd is much more pragmatic, and doesn't care if the graphics drivers are binary and propietary. Their goal is a competitor to Windows and reclaiming the desktop, ending the MS monopoly over it (which gives MS the power to establish their standards easily).
Both actually have similar goals: the former want a free system, the latter want a free desktop. But their goals are in conflict with each other.
The problem is that Gnome and KDE have both have their own architectures. For example, KDE has kioslaves, Gnome has gnomevfs. Now, if you mount a share via gnomevfs, all Gnome apps can access it - and NO ONE ELSE. In Windows, ALL apps can use UNC paths (\\\\), ALL apps use the same file requester (except some 16-bit ones) etc.
Additionally, the Windows UI is generally more responsive than Gtk ones; Qt is pretty fast, but Gtk UIs tend to behave like slugs. Thunderbird or Evolution, for example, and trying to scroll through 800 emails, the emails list redraws itself so slowly that scrolling becomes an exercise in patience; in Windows, I can scroll smoothly. This seems to be because of very slow font rendering (I had the same scrolling problem when viewing the email contents, until I switched the font to Terminus; unfortunately, it seems to be impossible to use Terminus in the emails list).
Window redrawing, moving etc. works extremely well with AIGLX, but when the windows get resized, and the toolkit kicks in, things suddenly repaint slow as if everything gets repainted by putpixel() calls. And yes, this CAN be improved. Look at e17; they can repaint the WHOLE DAMN SCREEN and it is a thounsand times faster than Gtk, mainly because they do it much smarter and retain the drawcalls until a final flush is invoked, thus giving the system the chance to clip partially visible and kick out invisible and duplicate elements. Additionally, blending can be done correctly without worrying about the correct order in the app (the system takes care of the final sorting). In contrast, Gtk paints immediately, thus giving away the chance of said optimizations.
So, while WMP7+ is horrid, horrid software, I wouldn't say that the clear winner on Windows is a Free alternative.
It is: search for Media Player Classic, Real Alternative, Quicktime Alternative.
Media Player Classic is an excellent player in an improved WMP6-style. Very responsive, slick interface, extensive functionality. Real & Quicktime Alternative are MPC-backends for playing Real/Quicktime streams *without* the need for Real and/or Quicktime player. These backends do not play all rm/mov files, but most.
Now, if MS would design the WMP UI like the one in MPC, WMP would be an option again.