Re: Standard way of graphics in Linux

Herbert Kleebauer wrote:

Ok, have to accept that all the things are much more complicated
in Linux than in Windows.

Explain? You can't access hardware in low levels using Assembler in
OSes like e.g. Windows XP. Or did I miss something?

Either I have to spend a huge amount of time reading documentation
or stop my trip to Linux.

Did you expect that Linux is a bad copy of Windows? Surely you'll
have to read docs if you want to program on such a low level.

Wolfgang Draxinger wrote:

The lowest level you can use, is the one, the kernel gives you.
That are the syscalls.

Would like to use an int 80 function, but found nothing which
opens a window and does a bitblt to it. Didn't even find something
for keyboard input.

Just for personal interest: What do you want to achieve *in the

Linux is a multitasking operating
systems, which means, you can't just manipulate each and every
pice of the hardware like you want.

Windows is also a multitasking operating systems and has no
problem to provide a built-in graphics interface.

What do you mean by "built in"? It's the same difference here
between Windows and Linux as it's almost everywhere: Windows has a
default way to go, which is mostly the only one available. Linux
has many to choose from, with some that are present almost
everywhere (GTK, SDL and perhaps Qt)

Sorry, it's just not possible. The kernel is responsible for the
low level stuff, you're doing high level.

Exactly that's the problem, the kernel is responsible for the low
level stuff but doesn't provide any support for graphics output
(as far as I understand it).

It does. Have a look at the Linux kernel docs (subdirectory fb). How
else do you think the X server displays graphics?

This is done by add-ons

What is an "add-on"? In Windows, kernel add-ons are called "driver".
In Linux, that's called "kernel module".

, but the problem is, there seems to be no (or better many)
standard for this add-on.

What do you mean? No, libraries like SDL, GTK and Qt work in
userspace. You could compare them with MFC.

I don't think Linux will be able to compete with Windows on the
end user desktop market as long as there is no reference system
for a Linux desktop system specified.

I don't understand what you mean. There are many standard ways
(i.e., APIs) to program applications with GUI in Linux distros. You
should have read the most important ones already in this thread.

And a program (graphic + sound) designed for such a reference
system must be executable on any current and future x86 Linux
system which calls itself a "Linux Desktop System" without

Why does it have to? Because it is that way in Windows? 8)

(I still can execute 20 years old DOS binaries in XP).

LOL. There are countless counter-examples. And as luck would have
it, all of them are DOS programs which require low-level hardware
access (even Windows 3.1 binaries are not completely compatible to
modern Windows). That's what emulators, like dosbox, are for. BTW,
dosbox runs under Linux, too.

My current feeling is, Linux is a nice server system (I have a
Linux 1.1.18


continuos running since 12 years now on a 486DX2 as an FTP server
without any problem)

I hope it's not attached to the internet ;)

but as a desktop system it can't compete with Windows.

How long have you been using Linux as desktop system? My impression
is: Not for long.



BOFH excuse #127:

Sticky bits on disk.