Linuxon működik, csak Windowson problémás az ilyen file megnyitása, ott kellene hozzá írni egy fopen() wrappert és az összes fopen() hívást arra cserélni.
Azt gondoltam, hogy megy, mert nincs agyonbonyolitva, vegulis barmi byte stream lehet a file neve, ha nincs benne zero byte (end of string) vagy '/' jel (directory separator). Szoval lehet akar utf-8 encode-olt cucc is, a linux kernel "nem tudja" hogy mi az, neki byte-ok sorozata csak, ha utf8, ha us-ascii, ha barmi mas stb. Ezert nem ertem windows-t stb ahol kepesek ezt annyira agyonbonyolitani, hogy mindig csak a baj van vele, pedig tok egyszeru lenne amugy
Jo persze, ha egy filesystem-en keverve hasznal az ember kulonbozo encoding-ot, az mondjuk gaz lehet, az igaz.
Amugy eleve, sok kulonbseg van unix/windows kozott, mar fopen()-nel is, ahol windows-on van kulon binary mod es text, mig unix-oknal ilyen altalaban nincs. Ha low level-ebb
I/O-t nezunk es open(), ott pl Xemu-ba bele kellett hack-elnem az O_BINARY-t, mert windows meg itt kulonbseget tesz binary es text I/O kozott, ezert mindig hasznalok O_BINARY-t, csak unix eseten ez zeronak van definialva, igy a mode-hoz OR-olva semmit nem okoz ott
Na, en ilyenekre mondom, hogy szerintem mar kb a hasznalhatatlansag hataraig tulbonyolitottak a windows-t (ja, lehet mondani, hogy a kompatibilitas miatt kell, de varjunk csak, miota van unix es windows? mintha unix regebbi lenne, megsincs annyi gondja ezekkel _altalaban_ .... na jo, kivetelek persze elfordulnak).
