NT (not Windows) is used plenty. But almost all software we use has a Linux port. We use NT boxes here and the primary application locking them in is LightWave. It is unclear why NewTex refuses to do a Linux port of at least the renderer (considering they do a Mac OS9 and OSX port, they can't claim they are using some MS-specific stuff).
The NT boxes are mostly SGI 320's, a total waste of money, as they will not run either new version of NT or Linux, and will probably be trashed before the much older and slower SGI workstations that are all over the place.
A lot of practical non-high-level stuff is Windows only. Movie format players in particular. Java interpreters that work for the nasty Oracle forms served up by our HR department. The usual crap that locks everybody into Windows, like Word/Excel documents (though that is not too bad). Often peripheral devices like scanners and digitizers require purchase of an NT machine to interface to them.
Just for clarification, Kodak's Cineon file format (which they consider to be equal or superior to film storage) uses 10 bits (not 8 or 12) for each color channel. What is stored is the log10 of the density of the film negative (the fraction of light that passes through is 1/density), each digit in the file represents.002 increase in the log10 of the density. The entire range is thus pow(10,2.048) or 111.68 contrast ratio, and using a logarithim allows the numbers to be spaced very closely equal to how sensitive the eye is to the light levels. The file is not compressed, and in fact wastes 2 bits per pixel (some places put these two bits on the green to make it 12 bits).
Exceeding normal film resolution requires a 35mm full-aperature film frame (which is half the dimensions or 1/4 area of a 35mm still frame) to be 4096 pixels wide and 3112 tall, and CCD film scannars are built to this resolution. For normal use in special effects this is immediately halved to 2048 wide but you can make a good argument that this noticably degrades the picture.
Therefore for a lossless storage of a still 35mm image I would estimate a maximum of 4*4096*3112*3*10 bits, about 182 Megabytes.
I would completely expect a parser library, just like for XML.
The main purpose of eliminating escape sequences is so that the parser can produce pointers to the input buffer and lengths to indicate the text data. The need to allocate copies of all the string data is one of the reasons XML parsing is not suitable for data transfer.
I admit that as it is typed the syntax is ugly. However if tab characters were shown as ^I by your favorite text editor you would think it ugly as well. We should admit that the raw data does not have to be viewed by humans with old software, and make editors that handle this correctly.
IMHO this is useless, it wastes a lot of memory and makes programs fail sooner (pages that are never written to or are immediately freed due to exec would take up space). More importantly this solves nothing, as memory does not necessarily run out when *your* process calls malloc, it runs out when *some* process calls malloc. Maybe in the old days when system calls did not require memory to be allocated this scheme would have worked but not anymore. I have no idea what a real solution is, but I kind of suspect nobody does...
Nonsense. All the XML I have seen insists on using 1-letter command names in order to get things reasonably short. I fully agree with the original poster, having shorter close tags would probably halve the reasons for these short tags and actually make things more readable.
In my opinion XML is a mistake. We should have copied ASCII design, which reserved 32 control characters for exactly this purpose.
I would like to see an XML replacement where the text is UTF-8, there are NO "escape" sequences. And "<" is replaced with the control character "^[", ">" is replaced with "^\", close commands replaced with "^]", and '="' is replaced with "^[" and closing quote replaced with "^]".
This would change "<command arg="foo">data</command>" into "^[command arg^[foo^]^\data^]" and would be much easier for a program to parse and editors could be made to display this in a user-friendly way just like they special-case ^J and ^I now.
Other more controversial ideas I had:
^A, ^B, etc (all except ^I..^M) mean the same as ^[A^\, etc, so they are 1-byte shortcuts for all 1-letter commands.
^^...^J is a comment, ie ^^ is defined as introducing an end-of-line comment. This can also be used to remove linebreaks from the data.
The sequence ^M^J should cause the machine to crash immediately:=)
Imbedding the non-DLLEXPORT class may work but I think it produces nasty warning messages from the compiler about doing it. What also works is to put DLLEXPORT on each individual public+protected method rather than on the entire class. This of course looks incredibly ugly in the header file, I think this crap will still pollute header files for decades after Windows has disappeared, just like K&R vs Ansi prototype macros still pollute most of the Unix header files.
It would be nice if the class DLLEXPORT just exported the public (and maybe the protected) methods. I think they export all of them so that inline public methods that call them can be compiled. The compiler could reliable check for this, though.
Of course it would be even better if the missing symbol was just missing from the DLL, like it is in Linux.so files. I don't understand why they can't do this, I thought there was a problem with reserving "slots" in the DLL, but it is obvious that DLL's work if you add or delete unused exported symbols from them, so I don't know what is going on. Probably stupidity.
If I make Uncoypyable be "class _declspec(DLLIMPORT) Uncopyable..." I can compile the library (if I leave out the commented-out lines, as you said). However I cannot link with it unless I also comment out the assignment operators from the header. It appears that something in the linking process with a.dll requires that all symbols declared with APIENTRY must exist.
The reason the depth cannot be changed is because of the incredible stupid "visuals" design of X, which requires a program to learn intricate details about how the memory of the screen is laid out and convert all images and colors to the screen format to be drawn. These programs expect to choose the visuals from a fixed set that are possible at all times (which matches a hardware design made when color was first introduced but does not match any hardware now). Programs do a lot of startup calculations and storage of data about the selected visual and are not prepared to have this data change.
My proposed fix is to scrap visuals completely. For back compatability the server would advertise one TrueColor visual with support for all image formats of n*pow(2,m) bits, where n is 1,3,or 4 and m is 0,1,2,3, or 4.
A new interface would be provided for the few programs that care about the actual frame buffer format, and a new event that says "the frame buffer format changed" that indicates this information changed.
As for the resolution changing, the reason is that the window managers assumme the root window will not change size and are unprepared to move the windows. The programs also get the screen size when they are run, but most do not use this for anything and it is probably ok if it is wrong.
This sounds much easier to fix, however, and I'm not sure why it has not been done. I propose that the X server send a normal ConfigureNotify event to the root window when it's size changes. Window managers could be rewritten to look for this and respond as needed to move the windows so they are all on the screen. It may also be a good idea to add some interface that Xlib would use to stuff the new values of the screen width/height into the XDisplay structure, though that is probably not that important (lots of Windoze programs also cache the screen size at startup and don't handle screen resizes all that well...)
The X-Render extension is not the equivalent of the OS-X transparent compositing of windows. Though I can see ways that X could be made to do this, but not without some serious changes.
The most important change is that X needs clean double-buffering support such that any window the system wants to is double buffered. The main thing needed is a call added (to Xlib and to all applications) to "flush" the current display to tell the system it is time for the back buffer to go to the front. This will allow X to do all it's graphics to the back buffer.
There also needs to be transparency in the current color. Lets get an interface in there where the program can ask for the color with a single 32-bit unsigned value, 8 bits of r,g,b, and alpha. Provide another interface for the tiny, tiny minority of programs that need colors in higher resolution than this. This means we must ditch colormaps, and I think all visuals should be gotten rid of (for back compatability all servers will claim to support a single truecolor visual with 8 bits of rgb).
Scrap the window manager and make the toolkits draw their own window borders.
Actually if some problems with the Xlib protocol could be fixed, it would be much faster than kernel calls. This is because many operations can be packed together into a single buffer before a context switch is done. This means that fewer than one context switch per operation.
The problem with this is stupid stuff in Xlib that requres synchronization betwen the app and the server. A simple example is setting a color typically requires a round trip to allocate a color. More of a concern is that almost everything with window managers use atoms (a round trip to register each one) and many of the calls to do things to windows return values, or require even heavier work to synchronize with the window manager.
Unfortunately I don't see the Xlib people rushing to fix this. Even a "register these thousand atoms at once" call has not been added, though SGI has had this extension for years.
Image data does not go through shared memory without an enormous amount of work on my part writing the program. Part of the problem with X is a refusal to write simple clear interfaces, and the X shared memory extension is one. I would much prefer an interface where I used the same call whether or not shared memory is used, and if shared memory was better it was automatically set up. And don't say "use the GTK (or other widgetset) drawing library". The basic X interface should resemble these drawing libraries, there is no reason for this incredible complexity and slowness.
Re:Aqua l'n'f or native Aqua implementation?
on
Qt Released For OS X
·
· Score: 2
They are not using native widgets. They are emulating the Aqua look-n-feel as a Qt theme.
Anybody who thinks you can make a portable toolit using native widgets has not tried to write one.
As I understand it, the Aqua look-n-feel could easily be ported to other platforms, but Apple is not allowing that. It is also possible it uses OSX calls to draw some parts of the look-n-feel, this sounds like a reasonable idea since it is not supposed to run on other platforms. However I expect these calls are on the level of "draw a rounded translucent shape this big here", ie much lower than any toolkit interface.
Re:will a preemptible kernel solve the dos problem
on
Linux Kernel Bugs
·
· Score: 2
This is a good question, I was wondering about this with with the previous discussion about pre-emptiable kernels.
It would seem that preemptible kernels would allow kernel functions to be written to take arbitrarily long times, and only the calling process is hurt by this. This would avoid the DoS attack, but more importantly I would think it would make a lot of kernel stuff much easier to write and the code much easier to read and debug.
So do any experts in kernel design think this, or am I totally wrong?
Actually I *want* the users to be able to create the objects on the stack. Something like this:
function() {
Fl_Window window(...);
Fl_Input textfield(...);// this is in the window
Fl_Button okbutton(...);// also in window
window.show();// put it on the screen
(wait for user to hit ok button)
return result;
}// this destroys the window & widgets
I have tried to stop the copy & assignment by making them private and undefined. Unfortunately the stupid MicroSoft VC++ does not like this, and you have to give dummy implementations, which means that code that has rights to call private functions are still not prevented from compiling with assignments and copy constructors. Stupid MicroSoft strikes again!
The window manager is a problem when you create windows and when you move and resize them. However it does not interfere with the actual drawing of the window contents at all, they are the same speed as if there was no window manager.
Most of Xlib's problems are the enormous numbers of calls that return a value, thus requiring synchronization between the server and client. For instance to draw in an arbitrary color the program needs to ask for the color cell (a round trip) and then set the color cell in as the foreground color and draw (not a round trip). Yes of course any real program will remember the color cell after the first call, but many other things in X require round trips all the time. If no Xlib calls returned a value I think the stream buffering would result in far less context switches than even Windows where the system is put into the kernel.
You are correct that window managers were made before there were shared libraries (or at least before there were shared libraries that the user could easily change). If we could fix this now, I would actually put the entire window into the toolkit. If people wanted the window behavior or borders to change this would be a themable part of the toolkit. Actually I would expect we would be able to get rid of the window borders entirely, which would go a long way toward making a user-friendly and attractive interface.
My toolkit fltk does things similar to Qt: when you destroy a "containier" widget it destroys all the inner widgets for you, even though you had to use "new" to create all those child widgets.
I have to admit this has caused problems, though for most programs the code savings is enormous (because fltk has to keep track of all the child widgets anyways, this avoids the need for the program to do so just to be able to delete them).
I solved a lot of this with a hack: I made the destructor change part of the object (the "parent widget pointer") to null, and container destructors don't destroy child widgets unless the parent pointer is equal to them, thus avoiding double destructors. This is theoretically bad programming practice but as far as I can tell has never failed. It allows widgets to be local variables, and imbedded (non pointer) members of larger structures, which Qt does not allow, this has proved to be very useful! However it still fails if the programmer calls the destructor after destroying the container.
Unfortunately this is why Qt works at all. It is absolutely impossible to make a portable library that interfaces to a high-level toolkit like interface. This was tried with things like wxWindows that tried to run atop Win32 widgets and Motif. Where are those toolkits now?
There is a serious problem with the system designers being so full of themselves that they think they can dictate things like toolkits. The should be spending their time on hard stuff, like advanced rendering models, and stop thinking they are cool because they can program a new type of drop-down menu.
Unfortunately Qt itself seems to be suffering from this too. A lot of this very useful stuff (like the antialiased rendering) is intricately linked to their toolkit such that it is impossible to use it without also using Qt. I am hoping they will start to fix this, as it is probably becoming an unimaginable maintenence mess unless they start looking at layers of libraries.
I would consider using Qt if they would stop copying some of the stupider Windoze things: allow Emacs ctrl keys in the edit widgets, fix the dragging of scrollbars so they don't go back if you drag diagonally, make the "combo box" pop up with the currently selected item under the mouse and make it the full height of the screen, don't move the focus when you click on buttons, allow buttons in the menubar so we don't need a seperate "toolbar", and put the filenames in a single column in the file chooser. KDE needs to fix the window manager to not raise windows when you click on them, and allow windows to be repositioned without raising them. There are a dozen other little problems like this. Until we stop seeing this crap there are going to be people like me who will refuse to use Qt.
Linus: and if they improve latency noticeably I'd really rather look at why the latency is bad
in the first place.
I don't really agree with this. I would imagine that there are many things in the kernel that could be written much cleaner, smaller, and faster if the writer did not have to worry about latency. Since making the kernel pre-emptable would allow this I could see things actually improving as a result.
PS: I don't know anything about kernel design, so ignore my comment if necessary...
The X interface is not slow due to the network abstraction, it is slow because of incredibly bad design of the Xlib calls themselves, requiring a huge amount of synchronous calls to the server. The network abstraction could actually speed things up enormously by providing a convienent way to batch tens of thousands of calls into a single context switch, if it were not for the enormous number of calls that return a value from the server and thus require synchronization.
As to the original subject, I think there is some confusion on both sides. That NT provides a user-friendly method of controlling things is a point in it's favor over Linux where the designers insist that nothing be easy for the end user. However it is true that the NT switch is equivalent to the Unix "nice" command that existed decades before anybody dreamed of pre-emptive kernels.
Personally I would like to see a system were there were as few controls as possible. Any kind of adjustments like this indicate to me that the designers really don't know how to get performance as good as possible. If games require different scheduling than seti@home, I would like to see a kernel that recongnizes the behavior of the programs and adjusts. This would be way better than requiring the user to do this, no matter how user-friendly the button is!
My GUI toolkit fltk is ported to Win32. It is pretty obvious from the patch submissions, questions, and bug reports, that at least 3/4 of the users are Win32 programmers, most of who have never even touched a Linux machine.
To me it is pretty obvious that there is a lot of interest in open source software on Win32 platforms.
USC2 has been officially rejected by the standards bodies in preference for UTF-16. Also USC2 would still encode accent prefix characters which pretty much requires your program to think about multiple widths anyway.
I also believe the added complexity of needing to handle both 8-bit text and USC2 is way more complex than just using UTF-8 everywhere. I also have never seen an algorithim where the location of characters are calculated directly, rather than being offsets calculated by scanning all the letters before that point in a string. This means that variable-sized characters do not complicate any known algorithims.
"Wide characters" have delayed our ability to get working internationalization for decades now. I strongly recommend that you stop contributing to this shameful history and start working with something that works like UTF-8.
I have recieved many many patches to my own LGPL software (fltk) adding all kinds of features that people needed.
I think in general anybody adding a feature for their own use wants to see their code in the main version. They don't want to have to keep patching it with their modifications every time you make a new version. They also worry that you will provide that feature in a different way and get credit for your idea. Also they worry you will change the code such that their modifications can't work or have to be rewritten.
I also think anybody who does not want to contribute back to the original code is not going to be stopped just because of a clause in the license.
So I would ignore this. Make sure it is easy for people to contact you and respond to any patches sent (even if you don't put them in).
All implementations reading UTF-8 should treat characters coded using more bytes than necessary as errors. Otherwise serious security vulnerabilities are possible due to disagreement between various pieces of software about the equality of characters.
Normally these errors are turned into a single error Unicode character (0xFFEF?). However I favor an implementation where the error is turned into the same number of characters as there are bytes in the error, with each character equal to the original byte. Due to the design of UTF-8 the resulting characters will be in the 0x80-0xFF range. The reason for this is to allow recovery of ISO-8859-1 text that is mistakenly put into a UTF-8 stream.
Slashdot Mirror
The NT boxes are mostly SGI 320's, a total waste of money, as they will not run either new version of NT or Linux, and will probably be trashed before the much older and slower SGI workstations that are all over the place.
A lot of practical non-high-level stuff is Windows only. Movie format players in particular. Java interpreters that work for the nasty Oracle forms served up by our HR department. The usual crap that locks everybody into Windows, like Word/Excel documents (though that is not too bad). Often peripheral devices like scanners and digitizers require purchase of an NT machine to interface to them.
Exceeding normal film resolution requires a 35mm full-aperature film frame (which is half the dimensions or 1/4 area of a 35mm still frame) to be 4096 pixels wide and 3112 tall, and CCD film scannars are built to this resolution. For normal use in special effects this is immediately halved to 2048 wide but you can make a good argument that this noticably degrades the picture.
Therefore for a lossless storage of a still 35mm image I would estimate a maximum of 4*4096*3112*3*10 bits, about 182 Megabytes.
The main purpose of eliminating escape sequences is so that the parser can produce pointers to the input buffer and lengths to indicate the text data. The need to allocate copies of all the string data is one of the reasons XML parsing is not suitable for data transfer.
I admit that as it is typed the syntax is ugly. However if tab characters were shown as ^I by your favorite text editor you would think it ugly as well. We should admit that the raw data does not have to be viewed by humans with old software, and make editors that handle this correctly.
IMHO this is useless, it wastes a lot of memory and makes programs fail sooner (pages that are never written to or are immediately freed due to exec would take up space). More importantly this solves nothing, as memory does not necessarily run out when *your* process calls malloc, it runs out when *some* process calls malloc. Maybe in the old days when system calls did not require memory to be allocated this scheme would have worked but not anymore. I have no idea what a real solution is, but I kind of suspect nobody does...
Nonsense. All the XML I have seen insists on using 1-letter command names in order to get things reasonably short. I fully agree with the original poster, having shorter close tags would probably halve the reasons for these short tags and actually make things more readable.
In my opinion XML is a mistake. We should have copied ASCII design, which reserved 32 control characters for exactly this purpose.
I would like to see an XML replacement where the text is UTF-8, there are NO "escape" sequences. And "<" is replaced with the control character "^[", ">" is replaced with "^\", close commands replaced with "^]", and '="' is replaced with "^[" and closing quote replaced with "^]".
This would change "<command arg="foo">data</command>" into "^[command arg^[foo^]^\data^]" and would be much easier for a program to parse and editors could be made to display this in a user-friendly way just like they special-case ^J and ^I now.
Other more controversial ideas I had:
^A, ^B, etc (all except ^I..^M) mean the same as ^[A^\, etc, so they are 1-byte shortcuts for all 1-letter commands.
^^...^J is a comment, ie ^^ is defined as introducing an end-of-line comment. This can also be used to remove linebreaks from the data.
The sequence ^M^J should cause the machine to crash immediately :=)
It would be nice if the class DLLEXPORT just exported the public (and maybe the protected) methods. I think they export all of them so that inline public methods that call them can be compiled. The compiler could reliable check for this, though.
Of course it would be even better if the missing symbol was just missing from the DLL, like it is in Linux .so files. I don't understand why they can't do this, I thought there was a problem with reserving "slots" in the DLL, but it is obvious that DLL's work if you add or delete unused exported symbols from them, so I don't know what is going on. Probably stupidity.
If I make Uncoypyable be "class _declspec(DLLIMPORT) Uncopyable..." I can compile the library (if I leave out the commented-out lines, as you said). However I cannot link with it unless I also comment out the assignment operators from the header. It appears that something in the linking process with a .dll requires that all symbols declared with APIENTRY must exist.
My proposed fix is to scrap visuals completely. For back compatability the server would advertise one TrueColor visual with support for all image formats of n*pow(2,m) bits, where n is 1,3,or 4 and m is 0,1,2,3, or 4.
A new interface would be provided for the few programs that care about the actual frame buffer format, and a new event that says "the frame buffer format changed" that indicates this information changed.
As for the resolution changing, the reason is that the window managers assumme the root window will not change size and are unprepared to move the windows. The programs also get the screen size when they are run, but most do not use this for anything and it is probably ok if it is wrong.
This sounds much easier to fix, however, and I'm not sure why it has not been done. I propose that the X server send a normal ConfigureNotify event to the root window when it's size changes. Window managers could be rewritten to look for this and respond as needed to move the windows so they are all on the screen. It may also be a good idea to add some interface that Xlib would use to stuff the new values of the screen width/height into the XDisplay structure, though that is probably not that important (lots of Windoze programs also cache the screen size at startup and don't handle screen resizes all that well...)
I'm not sure why nobody has added this.
The most important change is that X needs clean double-buffering support such that any window the system wants to is double buffered. The main thing needed is a call added (to Xlib and to all applications) to "flush" the current display to tell the system it is time for the back buffer to go to the front. This will allow X to do all it's graphics to the back buffer.
There also needs to be transparency in the current color. Lets get an interface in there where the program can ask for the color with a single 32-bit unsigned value, 8 bits of r,g,b, and alpha. Provide another interface for the tiny, tiny minority of programs that need colors in higher resolution than this. This means we must ditch colormaps, and I think all visuals should be gotten rid of (for back compatability all servers will claim to support a single truecolor visual with 8 bits of rgb).
Scrap the window manager and make the toolkits draw their own window borders.
The problem with this is stupid stuff in Xlib that requres synchronization betwen the app and the server. A simple example is setting a color typically requires a round trip to allocate a color. More of a concern is that almost everything with window managers use atoms (a round trip to register each one) and many of the calls to do things to windows return values, or require even heavier work to synchronize with the window manager.
Unfortunately I don't see the Xlib people rushing to fix this. Even a "register these thousand atoms at once" call has not been added, though SGI has had this extension for years.
Image data does not go through shared memory without an enormous amount of work on my part writing the program. Part of the problem with X is a refusal to write simple clear interfaces, and the X shared memory extension is one. I would much prefer an interface where I used the same call whether or not shared memory is used, and if shared memory was better it was automatically set up. And don't say "use the GTK (or other widgetset) drawing library". The basic X interface should resemble these drawing libraries, there is no reason for this incredible complexity and slowness.
Anybody who thinks you can make a portable toolit using native widgets has not tried to write one.
As I understand it, the Aqua look-n-feel could easily be ported to other platforms, but Apple is not allowing that. It is also possible it uses OSX calls to draw some parts of the look-n-feel, this sounds like a reasonable idea since it is not supposed to run on other platforms. However I expect these calls are on the level of "draw a rounded translucent shape this big here", ie much lower than any toolkit interface.
It would seem that preemptible kernels would allow kernel functions to be written to take arbitrarily long times, and only the calling process is hurt by this. This would avoid the DoS attack, but more importantly I would think it would make a lot of kernel stuff much easier to write and the code much easier to read and debug.
So do any experts in kernel design think this, or am I totally wrong?
You can get around it by ifdef'ing out the declaration when making the library, but this assummes that the library itself has been debugged.
function() {
// this is in the window
// also in window
// put it on the screen
// this destroys the window & widgets
Fl_Window window(...);
Fl_Input textfield(...);
Fl_Button okbutton(...);
window.show();
(wait for user to hit ok button)
return result;
}
I have tried to stop the copy & assignment by making them private and undefined. Unfortunately the stupid MicroSoft VC++ does not like this, and you have to give dummy implementations, which means that code that has rights to call private functions are still not prevented from compiling with assignments and copy constructors. Stupid MicroSoft strikes again!
The window manager is a problem when you create windows and when you move and resize them. However it does not interfere with the actual drawing of the window contents at all, they are the same speed as if there was no window manager.
Most of Xlib's problems are the enormous numbers of calls that return a value, thus requiring synchronization between the server and client. For instance to draw in an arbitrary color the program needs to ask for the color cell (a round trip) and then set the color cell in as the foreground color and draw (not a round trip). Yes of course any real program will remember the color cell after the first call, but many other things in X require round trips all the time. If no Xlib calls returned a value I think the stream buffering would result in far less context switches than even Windows where the system is put into the kernel.
You are correct that window managers were made before there were shared libraries (or at least before there were shared libraries that the user could easily change). If we could fix this now, I would actually put the entire window into the toolkit. If people wanted the window behavior or borders to change this would be a themable part of the toolkit. Actually I would expect we would be able to get rid of the window borders entirely, which would go a long way toward making a user-friendly and attractive interface.
I have to admit this has caused problems, though for most programs the code savings is enormous (because fltk has to keep track of all the child widgets anyways, this avoids the need for the program to do so just to be able to delete them).
I solved a lot of this with a hack: I made the destructor change part of the object (the "parent widget pointer") to null, and container destructors don't destroy child widgets unless the parent pointer is equal to them, thus avoiding double destructors. This is theoretically bad programming practice but as far as I can tell has never failed. It allows widgets to be local variables, and imbedded (non pointer) members of larger structures, which Qt does not allow, this has proved to be very useful! However it still fails if the programmer calls the destructor after destroying the container.
There is a serious problem with the system designers being so full of themselves that they think they can dictate things like toolkits. The should be spending their time on hard stuff, like advanced rendering models, and stop thinking they are cool because they can program a new type of drop-down menu.
Unfortunately Qt itself seems to be suffering from this too. A lot of this very useful stuff (like the antialiased rendering) is intricately linked to their toolkit such that it is impossible to use it without also using Qt. I am hoping they will start to fix this, as it is probably becoming an unimaginable maintenence mess unless they start looking at layers of libraries.
I would consider using Qt if they would stop copying some of the stupider Windoze things: allow Emacs ctrl keys in the edit widgets, fix the dragging of scrollbars so they don't go back if you drag diagonally, make the "combo box" pop up with the currently selected item under the mouse and make it the full height of the screen, don't move the focus when you click on buttons, allow buttons in the menubar so we don't need a seperate "toolbar", and put the filenames in a single column in the file chooser. KDE needs to fix the window manager to not raise windows when you click on them, and allow windows to be repositioned without raising them. There are a dozen other little problems like this. Until we stop seeing this crap there are going to be people like me who will refuse to use Qt.
in the first place.
I don't really agree with this. I would imagine that there are many things in the kernel that could be written much cleaner, smaller, and faster if the writer did not have to worry about latency. Since making the kernel pre-emptable would allow this I could see things actually improving as a result.
PS: I don't know anything about kernel design, so ignore my comment if necessary...
As to the original subject, I think there is some confusion on both sides. That NT provides a user-friendly method of controlling things is a point in it's favor over Linux where the designers insist that nothing be easy for the end user. However it is true that the NT switch is equivalent to the Unix "nice" command that existed decades before anybody dreamed of pre-emptive kernels.
Personally I would like to see a system were there were as few controls as possible. Any kind of adjustments like this indicate to me that the designers really don't know how to get performance as good as possible. If games require different scheduling than seti@home, I would like to see a kernel that recongnizes the behavior of the programs and adjusts. This would be way better than requiring the user to do this, no matter how user-friendly the button is!
You are confusing preemptive with multithreading.
To me it is pretty obvious that there is a lot of interest in open source software on Win32 platforms.
I also believe the added complexity of needing to handle both 8-bit text and USC2 is way more complex than just using UTF-8 everywhere. I also have never seen an algorithim where the location of characters are calculated directly, rather than being offsets calculated by scanning all the letters before that point in a string. This means that variable-sized characters do not complicate any known algorithims.
"Wide characters" have delayed our ability to get working internationalization for decades now. I strongly recommend that you stop contributing to this shameful history and start working with something that works like UTF-8.
I think in general anybody adding a feature for their own use wants to see their code in the main version. They don't want to have to keep patching it with their modifications every time you make a new version. They also worry that you will provide that feature in a different way and get credit for your idea. Also they worry you will change the code such that their modifications can't work or have to be rewritten.
I also think anybody who does not want to contribute back to the original code is not going to be stopped just because of a clause in the license.
So I would ignore this. Make sure it is easy for people to contact you and respond to any patches sent (even if you don't put them in).
Normally these errors are turned into a single error Unicode character (0xFFEF?). However I favor an implementation where the error is turned into the same number of characters as there are bytes in the error, with each character equal to the original byte. Due to the design of UTF-8 the resulting characters will be in the 0x80-0xFF range. The reason for this is to allow recovery of ISO-8859-1 text that is mistakenly put into a UTF-8 stream.