a cls program meglétének linux alatt akkora az esélye, mint egy lottó ötösnek, egy clear-re mutató cls linknek talán több, de egyúttal azon az egyen fog mûködni… ezt meg senki nem akarja.
Az esc sek.áknak, meg elvileg mindenhol mûködnie kéne… ezek dos, win, lin… sõt még java alatt is kell, hogy mûködjenek.

Ha elfelejtjük a dos/wint, akkor:
http://hup.hu/wiki/index.php/Programoz%C3%A1s_Linux_alatt_az_NCurses_f%C3%BCggv%C3%A9nyk%C3%B6nyvt%C3%A1r_haszn%C3%A1lat%C3%A1val

erre találták ki a méret optimalizációs paramétereket a c fordtónál… de úgyis nagyobb lesz, mint egy asm. kód, mert a hülyeségeit azért belerakja

Ez igaz, de én nem a programtól vagy a fordításának a módjától függõ méretre gondolok, hanem a runtime könyvtárra, ami minden compiler/linkernél más méretû.

Igen, de a THE-vel van néhány gondom:(
A kedites configfájlomban vannak fastdef-es részek, ezek nem mennek a the-vel, másrészt néhány billentyûkombinációt nem esz meg linux alatt:(

Azért köszi.

Ez nem az eredeti THE, a billentyûkombinációkat meg lehet oldani, pl. lásd az „ekezet” makrót. Minden csak beállítás kérdése, még az egérgombokra is rá lehet definiálni funkciókat. Nemrég vettem észre, hogy az eddig olvasható karakterek a monitor felbontás növelése után elsz@ródtak (a default színek miatt). Egyelõre egy „compat keditw” vagy „ringcmd compat keditw” olvashatóbbá teszi.

Jó, akkor 1 byte:

program.c:

fordítási parancs:

A 0 byte-on is gondolkodtam. Egyelõre nem megy :)))))

Mindig akad valaki, aki übereli a megoldásomat, de ez az egybájtos most fájt!
Persze, már az enyémben is csalás volt az include, csak nekem nincs olyan fantáziám, hogy még kombináljam is holmi makróval. Lehet, hogy ez az egész hülyeség volt, de szerintem tanulságos is.

De ha már itt tartunk, melyik fordító generálja szerintetek a legkisebb kódot?
(A GCC nem errõl híres.)