i haven't try FASM yet.
in console linux(no-x11-gtk-kde), is there any graphic example/possibility written in FASM?

--
regards

I'm working on that. But you might look into ncurses anyway. That is what I am writing ... a tutorial. Currently working on some macros, such as getmaxyx ...etc.

sorry, the limit of my expression,

i mean sort of these things: Pixel(raster image), Frame Buffer, allegro game library.

--
regards

Technically, you might find some programs that use SVGALIB, but there's not many of those. Console Linux *is almost always* text based; graphical apps (SVGALIB, DirectFB, X11, etc) are different in focus than console applications.

once, i thought so, and now, i don't think so.

linux FB enabled linux + qingy

i guess something in kernel must be patched by FASM and re-kernel-compiled!
To do so, FASM linux version need code improvement..

Quingy relies on DirectFB, there really isn't support for real graphics in the Linux kernel -- and that's the way it should be! You want as little as possible in the kernel, using libraries for everything else. Console != Graphical.

The kernel provides a framebuffer, but graphical programs written to use it are scarce. You could look at the 6.20 release of RetroForth for an SVGALIB based app. It starts from console mode, switches to a framebuffer, and when exited, returns to the console. IMO, that's the best way to handle graphics.

no svgalib please! it has quite defect for security, though i love it.
it doesn't matter only if i am using single user mode or non networking environment but who know?

IMHO, if svgalib,FB can do graphic, then FASM also can do it!

[console] > [FB] > [console] (X)

[always FB] (O)
--

The biggest flaw in SVGALIB is the need for programs using it to be SUID (root). This isn't a big deal, since a program needs to call vga_init(), which switches it back to a user mode program. Seriously, EVERYTHING can be a security risk; but that doesn't mean we shouldn't use them.

well, I'd guess you need to be root to write something to some /dev entry, maybe changing permissions (eg allow root group to rw, and the make your self a member of the root group, would be an easier way - if my guuess is correct

You're right. That's why SVGALIB apps have to be SUID (root permissions) to initialize a framebuffer. Once the framebuffer is created, and memory mapped into the applications memory space, SUID is no longer needed, so permissions are reset to a standard user.

If you're concerned about security, only run as root when you have no other choice. I'm not overly concerned since I'm the only user of my Linux system but some people have multiple users or are always connected to the internet, they should be concerned.

i found good links for DFB
http://yuri.webhop.org/dfb4u.html

For more, use directfb cvs version.
1. patch 2.6.7-bk16 to 2.6.7 (linux kernel)
2. patch fusion-linux-2.6.3 to linux-2.6.7-bk20+ck4
3. in DFB, ./configure --prefix=/usr --enable-multi --enable-zlib --with-gfxdrivers=nvidia(which is mine)
for more: ./configure --help
4.try neptune-0.1.6 (i can't download 0.1.10)

But without FASM, something will be lack i guess

Edit: neptune is not a real DirectFB-based GUI, it still use X11 ;( , they said it is due to their limit to the various Graphic Drivers. ah, MenuetOS..

A better option would be to write a kernel FB interface IN FASM as opposed to using DirectFB which is written in C. Personally, I'm still of the opinion that a console is for text and graphical apps are not console apps. I might just use the kernel framebuffer directly to provide graphics in a future release of RetroForth -- I'm tired of depending on constantly changing, bloated libraries

at http://linuxassembly.org in the asmutils there is an example of useing the frame buffer in assembly