pouët.net

Yes surely "all" people producing 4Ks on Windows think dynamic libraries suck. What can you get at with X11?

hey viznut!

I recall trying to do raw x11 through a socket for sesamstr as well, but in the end it took too much code to set up everything properly. Too bad i lost the source for this :(

You can always resort to fbcon, but that is a bit of a harsh requirement.

I guess you could also make some kind of nasty wrapper that executes glxgears with some LD_TRACE based trap, so that all opengl stuff is set up and then all you have to do is hook the right functions yourself. Of course this'd be Horrendously unportable.

Indeed, I'm not particularly interested in just getting a framebuffer, I want a compact and portable (and tiny) way of using SDL/OpenGL and some audio library.

Personally, I wouldn't go for SDL for super-small apps.. Maybe a new library similar to SDL, which is written with size efficiency in mind. It would take some time for it to be implemented for different platforms, but that's how it goes. OpenGL's a good idea however. You've got to get access to the 3d hardware anyway, and on many platforms you get the benefit of being able to (ab)use the external dependencies without contributing to the size of your app.

Now that I think of it, apps on Linux access SDL as an external installed lib.. so that's at least one platform where you can benefit from using SDL. As soon as you need to statically link or distribute SDL on another platform however (usually the case), it's not great sizecoding anymore.

1. 4k:s should be highly platform dependent, no big need to think about portability really
2. Wouldn't it be best to not rely on SDL..? If you could get a GL surface and then just stream sound to /dev/dsp...? Is the code for GL initialization too big for a 4k?

No idea how to do it under Linux but I should imagine it's larger that the 2 function calls you need to open a window with SDL.

I think "4k:s should be highly platform dependent" is the stupidest thing I've heard for a while. In the *nix world this would be pretty close to "4k:s should only work with a specific version of a specific set of dynamic libraries" which is just unacceptable.

Trying to run older 4ks which have been created with such a moronic "who cares about the future" attitude is such a pain in the arse that no one really cares about doing it. So, if someone wants their prod to be remember at later times, they should take compatibility issues seriously, especially when releasing on platforms where binary compatibility is not an obvious issue.

If I'm ever going to release a 1k/4k for *nix at some point of time, it's definitely going to talk in raw X11 (and perhaps GLX) protocol with pure kernel-level calls. (GLX may actually be cheaper than using plain X11 window with software-rendered framebuffer, by the way)

On Linux I don't think you can go much smaller than SDL, since it's just two function calls to get the GL screen up and running. Pretty much everybody has it installed nevertheless. The bigger problem is how to import functions from libraries, since that takes 20-30 compressed bytes per function and for any realistic GL code we easily need 10+.

About running those old Linux 4k's (by us): they expect to find libGL.so and if the symlink is not there they won't work.

That would be highly platform dependent then.

I see nothing wrong with SDL. It's the Linux equivalent of d3dx9_xx.dll, so to speak ;)

i thought d3dx9_xx was more like the d3d equivalent of glu32.dll, but anyway :)
(d3dx doesnt have functions to open windows and so on)

OK, technically it's more like GLU, that's right. I was just refering to the "that special library that's required by most demos" thing they both have in common :)

KeyJ, actually, the X11/GLX protocol and Linux kernel ABI are much more mature and fixed than any dynamic library ABI. Libraries tend to break their backward compatibility far more often than mature protocols and the Linux kernel do; even the GNU libc has broken its binary compatibility a couple of times during the last decade, so I really wouldn't like to trust it.

So, I sincerely believe that using X11/GLX via direct system calls without dynamic linking is the most compatible way when making a native Linux executable. And putting the source code available is of course a definite plus.

viznut, what you're advocating there is not ever trusting libc if you're writing something on linux. That's fairly absurd isn't it?

I don't think it's absurd to avoid relying on ABI compatibility with a particular build of libc. It seems to me that it's not really the *nix way to rely on such compatibility anyway - since it's pretty normal to compile from source for a particular platform. If you release only binaries, then you should expect the need to release new builds after some time (perhaps with no change to the source at all).

bigcheese, fair point and I have no intention of releasing without source so I'm alright on that front. Still though, what viznut is advocating is avoiding libraries altogether for the sake of compatibility; that doesn't sound like much fun to me ;)

Not just for the sake of compatibility but for the sake of trueness!

Anyway, coders are different. Personally, I find low-level coding with a relatively fixed programming interface much more fun than exploiting a vague and ever-growing set of libraries.

Also, I still believe that it might be possible to fit raw-socket GLX code in a smaller amount of bytes than what the overhead of dynamic linking takes, but I'll return to that after I have something to show :)

Yup, absolutely and it all comes down to what you consider philosophically acceptable. I'm aiming to do things that are competitive with current Windows size-coding stuff but your approach has its own merits.

It would be cool to have some sort of analysis of prods.. resulting in indication of which external dependencies exist. Over time, prods that have similar external dependencies could be more fairly weighed against one another in a fair manner.. so each smallprod class could be more of a lasting tradition. Overkill? Sure it is.

Quick update: After much haxxoring and research by myself and leblane we now have import by hash and a very small header (we worked together researching and sharing ideas and both got it working independently). The unpacked size of my header header and import code is:

339bytes + (strlen(libraryname)+9) bytes per library + 4 bytes per symbol

Leblane has a working version of Flow2 by auld in under 1024 bytes, I'm not sure what he's doing about making it available though.

I know this ain't new, but since no one posted the link, I'll put it here for those who have yet to see it
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

that's nuts :)

Aye it's cool and a useful document but that executable can't use external libraries and some of the tricks towards the end don't work anymore.

ahh that's too bad. i liked those the best :)

wow cool, i just discovered that in fact ELF was founded by iblis!