Slashdot Mirror

← Back to Stories (view on slashdot.org)

Any rxvt-Sized Unicode-Aware Terminal Emulators?

Posted by Cliff on from the evolution-of-the-terminal-window dept.

Viqsi writes "Just on a lark, I started a short while back to try to convert my environment totally to UTF-8. One of the big hangups that I've run into so far, however, is my X terminal emulator. I've been very happy with rxvt (I tend to have several $XTERMs open at once, so Low Memory is Good!), but it doesn't seem to support anything Unicode. A bit of searching has turned up nothing that isn't as big as or larger than xterm itself. So, the question -- are there any low-memory terminal emulators that support UTF-8, or any other Unicode encoding? (tabbed-window style terminals Don't Count, and that goes double for Konsole!)"

48 comments

  1. Why by Aknaton · · Score: 1

    is XTerm so large? I've been hearing about this for a while, as it is usally cited as a reason for using rxvt.

    I also have a question regarding Unix and Unicode.

    Although GNU/Linux and BSD systems can support Unicode libraries for the apps that need it, the OSes themselves use only ascii (from what I understand). Has there been, or ever will be, a form of Un*x that natively supports Unicode in all things? Or would doing such a thing create too many problems?

    1. Re:Why by RobKow · · Score: 1

      xterm is big because of the Tektronix graphical terminal emulation.

    2. Re:Why by Anonymous Coward · · Score: 2, Funny

      I thought it was so big because it has to contain the proper responses to anything that I type in it. For example "ls". How does it know?

    3. Re:Why by Anonymous Coward · · Score: 0
      "Native"... sounds like a microsoftism ;)

      Sorry - but you'll have to be a more specific. GTK and QT support unicode now, they're part of unix. Filesystem's support unicode (well, UTF-8). What bits are you talking about?

    4. Re:Why by dvdeug · · Score: 2

      the OSes themselves use only ascii (from what I understand).

      The OS's support arbitrary strings of 8-bit characters, which means they support UTF-8. There is no point in a modern Unix kernel where you would want to use UTF-8, and it won't let you, short of arbitrary hardware or standards limitations (weird foreign filesystems and what not.)

    5. Re:Why by Tet · · Score: 2
      is XTerm so large? I've been hearing about this for a while, as it is usally cited as a reason for using rxvt.

      Yes, it's really large. It uses 2.3MB of RAM on my machine, of which, 1.8 or so is shared with other processes. The sad fact is, though, that so is rxvt these days (and indeed, all current terminal emulators). xterm includes a tektronics emulator, amongst other things, which 99% of users will never need (in fact, I'm the only person I know that has ever had a genuine need for it). As a reaction to xterm's size, one of my lecturers at University wrote xvt, a minimal terminal emulator, without the bloat. Over time, that evolved into rxvt, which is growing more and more features, and is no longer as small as it once was. It's still smaller than xterm, but that's not hard. For comparison, opening up a new term uses up the following amount of RAM per new window:

      • 496: xterm
      • 296: rxvt
      • 856: gnome-terminal
      • 140: gnome-terminal --use-factory
      • 1068: konsole
      • 160: konsole (first new tab)
      • 36: konsole (subsequent new tabs)

      It should be noted that both konsole and gnome-terminal have massive startup costs, with konsole starting up 4 kdeinit processes, and gnome-terminal starting up gnome-pty-helper.

      --
      "The invisible and the non-existent look very much alike." -- Delos B. McKown
  2. Why yourself by fm6 · · Score: 2
    Has there been, or ever will be, a form of Un*x that natively supports Unicode in all things? Or would doing such a thing create too many problems?
    I don't know how difficult it'd be, but what's the motivation? End users, and even application developers, may need to interact using Han or Cyrillic or Hangul characters. But it's hard to see why a kernel hacker needs more than 2^7 characters.
    1. Re:Why yourself by keesh · · Score: 3, Insightful
      But it's hard to see why a kernel hacker needs more than 2^7 characters.


      Or more than 640KBytes of RAM. Or more than a 33MHz processor. For that matter, why do they need both uppercase and lowercase? Why do they want monitors? What's wrong with a VT100?

      The days of "sorry, no accents or unAmerican characters" are over. Unicode support at every level would be a big help for non-US-English development.
    2. Re:Why yourself by Anonymous Coward · · Score: 0
      Well yeah, I agree in principle, but then for a kernel they're programming in C and using english words for constructs anyway.

      Also, I completely understand why an individual would want to use unicode to support whatever language they want. But when you're hacking the kernel it's not an individual's project, it has to be read by many others. If those many others speak arabic too then that's fine, but all the linux developers write code in english and they (probably) expect to read it in english too.

      If I were to submit a patch in esperanto I doubt if it would be expected because there are fewer people who can maintain it. Multiple languages can (not necessarily are) a burden and they should be considered in the same way as a part of the program written in COBOL. There are fewer developers who could maintain it.

      Mostly though, it's all too vague again. The kernel internals probably isn't the place for multiple human languages, but the interfaces and the filesystem should definately be unicode. So far as I can tell they are already. What specifically should be unicode?

    3. Re:Why yourself by Papineau · · Score: 3, Informative

      It's not much for the internal strings (function names, variables, etc.), more for the messages that the kernel can send to the user (or root). For the first kind of strings, you'd have to redefine the C standard, and change compiler (and maybe also change text editor).

      When it boots, there's a whole slew of lines, many of which are purely numbers, but some of them could be localized (just as a big part of userland is). Now, since it would be in kernelspace, you'd maybe want to choose which one at compile time, but if you don't have access to a kind of Unicode for outputting strings, your choice of supported languages will be quite small.

      Now, this doesn't go in the argument if it's a desired behavior or not, just that it's something necessary before outputting for any language.

  3. Plan 9 uses Unicode. by Hobart · · Score: 2
    Has there been, or ever will be, a form of Un*x that natively supports Unicode in all things?

    From the 1995 paper describing "Plan 9" , the OS from the authors of Unix at Bell Labs:

    Another departure from ANSI C is that Plan 9 uses a 16-bit character set called Unicode [ISO10646, Unicode]. Although we stopped short of full internationalization, Plan 9 treats the representation of all major languages uniformly throughout all its software.
    --
    o/~ Join us now and share the software ...
    1. Re:Plan 9 uses Unicode. by norwoodites · · Score: 2

      Plan 9 is not UN*X but Mac OS X is and uses UTF-8 and UTF-16 for almost everything, and has a lot of fonts to support the different languages (Japanese, Chinese [Both traditional and Simplified], Korean, and other languages).

      Also Don't use any of the M$ products for the Mac because they do not support Unicode at all.

      Use OmniWeb for a Web Browser and Just use TextEditor for an word editor.

      Also Terminal uses UTF8 for the default encoding, you can change this if you want.

    2. Re:Plan 9 uses Unicode. by mirabilos · · Score: 2

      Actually, Mac OSX is not UNIX(tm), but it is as
      much Unix as OpenBSD, Linux, Windows NT/2000/XP are.

      Well, I wish OpenBSD hat native UTF-8 - currently it
      is totally locale unaware and just makes 8bit==latin-1
      assumptions.

      This does not mean I want NLS or I18N: localized
      error messages, locale in general, LANG= and LC_*=
      do suck a lot.

      --
      My Karma isn't excellent, damn it! (And /. still does not get UTF-8 right in 2012. Wow.)
    3. Re:Plan 9 uses Unicode. by norwoodites · · Score: 2

      Windows NT/2000/XP is no where near UN*X as much as Linux and *BSD are. Mainly because of the idea of a kernel and what goes into it.
      The Windows server in Windows NT/2K/XP is part of the kernel while under UN*X, it is an userland program. And also Mac OS X, *BSD are based loosely around the UNIX source. Also Linux is inspired by MINIX which is inspired by UNIX.

    4. Re:Plan 9 uses Unicode. by RevAaron · · Score: 2

      No sense arguing with this type of person- unless you're on this list you're not "Unix." Silly trademark issue. Apple hasn't paid the assload of money to get certified, nor as OpenBSD. So they're not "Unix." I say, who cares if it's called a car or an auto, still does the same damned thing.

      --

      Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
    5. Re:Plan 9 uses Unicode. by Anonymous Coward · · Score: 0

      Thats why he said UN*X and not UNIX(tm).

    6. Re:Plan 9 uses Unicode. by Hard_Code · · Score: 2

      "The Windows server in Windows NT/2K/XP is part of the kernel"

      If I remember correctly the "Windows" part of "Windows NT" is simply a "personality" which is hosted under the NT kernel. In the beginning Windows NT wasn't even going to be called "Windows" - it was just "NT". Only part-way through the development of the GUI-agnostic NT kernel, was the Windows personality added on (there was also a short lived OS/2 personality IIRC). So you're statement isn't so accurate. Now perhaps it actually lives in kernel space, or over time has integrated more or less with the kernel proper, but making this claim seems to be a standard "criticism" of NT. For all intents and purposes, operating systems should come with GUIs. I'd be glad if Linux (which is now being pitched as a desktop OS) actually came with real GUI support in the kernel. Or at least shift the video drivers from XFree into the kernel.

      --

      It's 10 PM. Do you know if you're un-American?
    7. Re:Plan 9 uses Unicode. by NNKK · · Score: 1

      NT isn't a Unix because it lacks a variety of very unix-y things. Stuff like BSD sockets, 'sh', an X implimentation, unix-like filesystem, unix-like permissions, and the visible filesystem layout is a nightmare (not that I'm a huge fan of unix-y layouts, but they're a darn sight better than Microsoft's layouts). It lacks a lot of unix-y libc stuff in a familier format (fork() comes immiediatly to mind, as I recently used it in some code I sent somebody running Win2k and had them come back to me saying "wtf do I do now?" and I wound up sending them cygwin to install rather than learning any of the win32 api; luckily this wasn't performance critical and I wasn't being paid for it).

      The fact that the kernel seems to be a bizzaire mess is not, in my mind, what prevents NT from being a "Unix". Sit me down infront of a system where everything is in the kernel and runs as one big 'file' and I'll call it a Unix if it does what a Unix is supposed to do and does it well. I'll say the programmers need to have their heads extracted by a qualified proctologist and subsequently beat with a sendmail manual, but I'll call it a Unix.

    8. Re:Plan 9 uses Unicode. by divbyzero · · Score: 2
      Or at least shift the video drivers from XFree into the kernel.

      You might want to look at the kernel framebuffer support. That's exactly what it does. My [somewhat uninformed] understanding of why there are still video drivers in both places is that:
      1. The Linux kernel framebuffer support is not yet all that mature.
      2. XFree86 is designed to be used with more systems than just Linux, and as such, cannot rely on the existence of an underlying framebuffer API.
      --
      But my grandest creation, as history will tell,
      Was Firefrorefiddle, the Fiend of the Fell.
    9. Re:Plan 9 uses Unicode. by Art+Deco · · Score: 1

      Mac OS X is BSD. BSD was UNIX long before X/open owned the trademark. Were their any justice in the world BSD would be grandfathered in as UNIX. After Ford purchased Mazda my Miata didn't become a Ford. I suppose Apple is big enough of a company to care about trademarks so they could conceivably spend the money to make Darwin UNIX 95 standard compliant and certify it. Then they could legally call it UNIX instead of *NIX or UNIX-like.

    10. Re:Plan 9 uses Unicode. by mirabilos · · Score: 1

      Well, to be exact, Mac OSX is a microkernel-OS
      which emulates a BSD-alike kernel. And it's got
      some of the old FreeBSD userland IIRC.

      --
      My Karma isn't excellent, damn it! (And /. still does not get UTF-8 right in 2012. Wow.)
  4. simple... by nbvb · · Score: 0, Flamebait

    nbvb@g4tower: open /Applications/Utilities/Terminal.app

    nbvb@g4tower: pwd
    /Applications/Utilities/Terminal.app/Contents /MacOS
    nbvb@g4tower: ls -l
    total 424
    -rwxrwxr-x 1 root admin 215164 Jul 17 18:43 Terminal

    nbvb@g4tower: sysctl -a | head -4
    kern.ostype = Darwin
    kern.osrelease = 6.0
    kern.osrevision = 199506
    kern.version = Darwin Kernel Version 6.0:
  5. freshmeat has many.... by therealmoose · · Score: 5, Insightful
    http://freshmeat.net/browse/158/?topic_id=158

    Ask slashdot is becoming increasing ridiculous, with the answer to almost every question found at either google or within OSDN. I don't mean to flame the editors, but it would be good if they would be a little more selective WRT ask slashdot.

    1. Re:freshmeat has many.... by Enrico+Pulatzo · · Score: 1

      The answer to most every question, I have found, can be answered in some fashion with google. Especially when the quality of answer you are searching for is that of slashdot discussions ;)

    2. Re:freshmeat has many.... by Viqsi · · Score: 1

      No, it doesn't. Note the "rxvt-sized" criterion. None of the apps listed there qualify. Most of them aren't $XTERMs at all, and I've tested all of the rest; they're all about xterm's size (in memory footprint) or larger.

      I'm not *that* dumb. :)

      --

      --
      viqsi - See "vixen"
      If we do not change our direction we are likely to end up where we are headed.
    3. Re:freshmeat has many.... by Komarosu · · Score: 1

      also... http://freshmeat.net/search/?q=UTF-8&trove_cat_id= 158&section=trove_cat see any xterms with full utf-8? :)

      --

      "What do you mean you have no ice? Do you expect me to drink this coffee hot?" - Random Customer, Clerks
  6. Context! Purpose! by fm6 · · Score: 2
    You know, there are applications that run perfectly fine in a small memory space, on a slow processor, and don't require fancy GUIs. I still enjoy playing old text-mode and low-rez computer games, designed in the days of 16K memory spaces and 1 Mhz processors. (I play them on emulators, not on the hardware they were originally designed for, but that's a matter of convenience and desk space.) High-powered systems are fun, and sometimes even useful -- but not every app needs them.

    The Linux kernel is not a very big entity -- which is a prime reason for its success. I find it hard to see what use it can make of extended character sets. And even if adding such a feature to the kernel had some benefit, there's a cost in terms of size. speed, and risk of bugs and security holes. You need to weigh the benefits against the risks, not just assume every bit of software in the world has to support UTF-32768. And the plain fact is, there doesn't seem to be any benefit at all.

    Perhaps I'm wrong. But to prove me wrong, you're going to have to suggest some real-world examples or scenarios that contradict me. Reciting cliches about vaguely relevent history says nothing.

    Note that I'm not attacking the general concept of Internationalized software. In point of fact, I spend a lot of time documenting the International features of my own company's products. All serious development tools support Internationalization. But they support it from the run-time-library level on up, where 99.99% of all development occurs.

    1. Re:Context! Purpose! by Jon+Peterson · · Score: 2

      I don't understand.

      If you are a kernel hacker (I'm not....), and you want to use chinese characters as variable names, why should you not be able to do that? Is that what you meant? Just which parts of a computer should only ever be referred to using glyphs from the Roman empire, and why?

      I can't think of any reason for any part of a computer system being ascii only, except the reason:

      "It's quite hard to change, and there's not much demand". Which is fine, but given that most people in the world can't communicate using ASCII, it's surely only a temporary excuse....

      --
      ----- .sig: file not found
    2. Re:Context! Purpose! by Anonymous Coward · · Score: 0

      you're confusing 2 separate issues.

      Kernel-level support for unicode basically means that all error strings are unicode (and probably gettext support so you can have a chinese error code). Of course, your terminal/text-screen video ram would need to support the chinese characters.

      Additionally, you'd need unicode-happy system calls (like unicode_open() and unicode_exec()) if they take a char *. Currently a moot point since extfs, etc aren't unicode happy. Slashdot isn't even unicode happy.

      you want to use chinese characters as variable names. That's a compiler/interpreter issue. It has nothing to do with the kernel. GCC supports trigraphs and wide-text. Take it up with the ANSI C steering committee. They specify legal C variable names.

    3. Re:Context! Purpose! by zerblat · · Score: 1
      Well, for starters, I doubt Linus would ever accept a patch with chinese (or any other non-english language) variable names. To be able to hack Linux you need to know at least enough English to understand what the existing code does. So, using English for your own code shouldn't be that big a problem.

      i18n is great, utf-8 is great, but using non-english languages when hacking free software is not so great -- at least if you want to share your code.

      At one point, the macro language used in MS Word (WordBasic or whatever) was translated into Swedish in the Swedish version. Everything was translated, including IF-THEN-ELSE statements etc. It was completely useless.

      I'm not sure what gcc would say if you started using non-ascii utf-8 in your variable names though...

      --
      Please alter my pants as fashion dictates.
    4. Re:Context! Purpose! by Anonymous Coward · · Score: 0

      I can think of only two reasons to have UTF-8 support for kernel and kernel development; The first one is that there may be more then one language support for kernel messages.

      For example: Instead of printing; "Kenel panic" it may print "Tyisnum pinkonik!" with its own character set (don't ask me in which language it was. I just made it up. However, for most of the people on this planet "Kernel Panic" means equally meaningless!

      Did you get my point?

      We may not care them for now, when the demand and contribution is small. But, it looks like it's not going to stay the same.

      The other reason would be being able to use foreign words (in its original char. set) as variables, which also requires some support from development utilities...

      (Note: I'm a non-English speaker.)

    5. Re:Context! Purpose! by dvdeug · · Score: 2

      If you are a kernel hacker (I'm not....), and you want to use chinese characters as variable names, why should you not be able to do that?

      Because the common language of kernel hackers is English.

    6. Re:Context! Purpose! by DNS-and-BIND · · Score: 1

      Ooh, how politically correct of you. God forbid anyone should be able to read linux source, much less its maintainers. It should be a tower of babel with patches in thai, chinese, and arabic.

      --
      Shutting down free speech with violence isn't fighting fascism. It IS fascism!
    7. Re:Context! Purpose! by fm6 · · Score: 2
      Actually, the Romans didn't invent most of our glyphs. The Romans didn't have J, U, W, Y or Z, and only used K when writing Greek words. And they didn't have lower-case letters or punctuation. All invented later.

      But I digress. You seem to be assuming that "Unicode support" is this magic thing you can add to any program and suddenly support every Unicode character. In fact, no program directly supports the complete Unicode character set -- Unicode was never meant to be used that way. Instead you support an "encoding" that gives you access to a manageable subset of Unicode.

      The most widely-used encoding is UTF-16, which supports a 2^16-character subset of Unicode. Most major programming languages support both ASCII and UTF-16. Some (notably Java and Visual Basic) support UTF-16 instead of ASCII. Unfortunately, the documentation for these languages usually refers to their their "wide" characters as "unicode" characters, as if Unicode were just a 16-bit "universal" character set. In fact, there are important Unicode-supported characters that are not in UTF-16.

      There's also UTF-8, a variable-width encoding that's backward-compatible with ASCII. I believe GCC already supports UTF-8, and could probably be made to support UTF-16, as most C compilers aready do. And since GCC is written in GCC, you could probably allow kernel programmers to use these extended character sets in their source code. But it's a tricky thing to do, and it's difficult to see the benefit.

      I hate the term "politically correct", but maybe it applies here. You seem to feel that any software that isn't character-set-agnostic is unfair to non-Western users. Putting such an assumption ahead of issues of reliability and security is a very poor kind of prioritizing.

  7. gnome-terminal --use-factory by sig · · Score: 3, Informative

    You can use gnome-terminal with the --use-factory option. It makes one process for all your terms, so if you have a lot of windows open, it doesn't use that much memory.

  8. Why so many xterms? by zeda · · Score: 3, Insightful

    Memory is cheap, why worry.

    Using screen also helps.

  9. Just try Konsole instead. by Anonymous Coward · · Score: 1, Insightful

    I know you said Konsole is out, and I can understand why. It does eat up quite a bit of memory initially. And yea you dont like it being tabbed, but it just takes a little getting use to. Every new "tab" in Konsole eats up less memory than Bash does. Give it a shot for 1 week.

    The shortcut for switching between console is is LShift+RArrow for going to the next console and LShift+LArrow for going to the previous console.

    You can name your consoles which is VEY handy. I frequently have 5-6 consoles open and name every one of them. It really helps. A little extra benifit of Konsole is that you can have customized profiles. One for Bash, one for ZSH, one for Midnight Commander, one for ...

    I didn't like it a lot at first but I grew to love it. Now I cant stand terminal programs that aren't like it.

    Mikey likes it.

    1. Re:Just try Konsole instead. by Anonymous Coward · · Score: 0

      > Every new "tab" in Konsole eats up less memory than Bash does.

      How can this be if every tab runs a new Bash plus overhead for the tab?

    2. Re:Just try Konsole instead. by Anonymous Coward · · Score: 0

      The amount of memory used for a new tab is less than what bash takes. See Bash is not a part of Konsole. Bash is a seperate program. So you can differentiate between the amount of memory it takes for a tab and the amount of memory it takes for bash. Here is a way to measure that.

      1) Run Konsole
      2) Run 'ps ux' in the console.
      3) Find the process your Konsole is running as. Then note the number in the RSS column, which we will call N1.
      4) Click the "New" button in Konsole to open up a new console.
      5) Run 'ps ux' again.
      6) Do step #3 again but call the new number N2.
      7) Do something similar to step #3, but find the process that the new bash is using. Then note its RSS column and call it N3.
      8) Here is the REALLY tricky step. Take N2-N1 and compare it against N3.

      I found out that (N2-N1) was less than N3, so that is how I determined that 'Every new "tab" in Konsole eays up less memory than Bash does'.

      Remember to keep in mind again that Bash is NOT a part of Konsole. Remember that BASH, KSH, ZSH, TCSH, CSH are all shells (that's why they all end in SH). Where as Konsole (which is like xterm and rxvt) is a terminal emulator.

  10. are there any rxvt sized terminal emulators? by Anonymous Coward · · Score: 0

    no

  11. Messages, variables by fm6 · · Score: 2
    OK, localized messages and variables are good reasons to have a internationalized kernel. But good enough to justify the costs? I don't see it.

    And before you accuse me of being English-centric, note that the guy who invented and still maintains the Linux kernel is not a native English speaker.

    1. Re:Messages, variables by Anonymous Coward · · Score: 0

      Sorry to be posting as anonymous (frank pohlmann). But first of allI am a bit surprised people want to make English the kernel developer's language of choice. What's wrong with our American cousins that they have to learn a few foreign languages for a change? It would not damage their brain cells I hope.

      Secondly, glibc has wide_char support (ISo 10646 oriented). so anyone who is NOT a kernel programmer, can indulge herself.

  12. Okay, I'll explain all my reasonings, then. by Viqsi · · Score: 1

    I wasn't wanting to point out *why* my criterion are the way they are, but here's a quick summary:

    1) I *like* having $XTERMs scattered everywhere. I use my $XTERMs as a Be-Anywhere-Doing-Anything type tool; ergo, concentrating them in one space would be counterproductive - hence, no tabbing. I'm odd that way.

    2) Memory isn't cheap on a laptop. I hate desktop systems. I'm odd that way.

    3) Excepting Opera (and it'll go the instant the Moz folks get their heads out of their asses about tabbing through links vs. tabbing through form elements), I want nothing at all to do with Qt. I just don't like it.ÂI more or less tolerate Opera only because I used it back in my Windows days and so am used to it already. I'm odd that way.

    4) I tend to leave a lot of terminal windows open to preserve state that may or may not be important. I'm ... well, you can prob'ly grok the pattern by now.

    The suggestion for gnome-terminal --use-factory would probably be best (is Way cool; I never knew about that before), except that gnome-terminal's i18n is broken at the moment. :)

    Such are my motivations for asking. Now You Know. :)

    --

    --
    viqsi - See "vixen"
    If we do not change our direction we are likely to end up where we are headed.
    1. Re:Okay, I'll explain all my reasonings, then. by zeda · · Score: 1

      The OS manages memory better than you, so let the OS do its job.

      Post a 'top' of your system and then everyone here can all get together and critique your memory usage. I'm sure there are other things you can stop using to save an extra K or two, so maybe you can splurge on an extra xterm.

      Don't expect other people to care all that much about your particular set of tradeoffs. If you care that much, take the xterm and cut out all the Tektronix graphics and other stuff yourself.

      If you are using xterms on multiple desktops, look into just using one and making it sticky.

      As far as saving state, nothing beats screen. It saves state even if X dies.

      You should get over your irrational problems with Qt also.

      You do realize that some of the old folks had to run good old xterms back in dinosaur times, on machines with half as much RAM as your laptop.

    2. Re:Okay, I'll explain all my reasonings, then. by Anonymous Coward · · Score: 0

      If you cant stand anything else, and you don't like the current situation, then you're absolutely fucked. Nothing you can do, give up. The only other solution is to write something yourself -- "scratch an itch" so to speak. Better projects have started that way.

  13. Yeah, insightful. by Anonymous Coward · · Score: 0

    As a brick.

  14. Now that you've mentioned this... by Anonymous Coward · · Score: 0

    Is this useful in any sense?

    I'm asking because:

    a) I'd advocate the removal of such code, as it seems not that necessary to applications and

    b) Has anyone made any software that uses such feature? Just out of curiosity... if it exists, why would someone use such emulation instead of X native graphics?

    c) Why has this been done in the first place? Just for the kicks?

    Thx.