???.txt

[Andras Tantos]

Hali!

>>> "aaa\bbb\ccc.txt\2", "aaa\bbb\ccc.txt\3" stb.. fajlokra mutatnanak.
>>> A struktura ezzel ekvivalens, semmi varazslat nincs benne.
>>
>> Nem ilyen egyszeru, de kb.
>
> Mi a kulonbseg?

Az, hogy megmarad a fajl es konyvtar kozotti kulonbsegtetel.

>> Igy egy forditoval integralt 'make', kb. ugy, mint ahogy a Turbo Pascal
>> csinalta, sokkal gyorsabban meg tudna talalni az ujraforditando fajlok
>> koret. Raadasul a forditasi konyvtar nem lenne osszeszemetelve .obj, meg
>> egyeb fajlokkal.
>
> Ez a pascalnal altalaban mashogy muxik, ebben jobb a pascal mint a C.
> De nincs gond a szemetelessel, be kell allitani hogy az objektek egy kulon
> konyvtarba keruljenek. A legtobb IDE-s forditoval ez alapbol igy megy.
> Makefile eseten turni kell egy picit.
> De ha nem tetszik, a fent kifejtett konyvtaras megoldas 100% megoldja
> ezt is, a kompatibilitas megtartasa mellett.

Mindent meg lehet csinalni. Vannak ra elegans es kevesbe elegans megoldasok. 
Megint csak: nem mondom, hogy ez az egyetlen megoldas, nyilvan nem az. Ez 
egy lehetseges megoldas, a maga elonyeivel es hatranyaival.

>> Oh, nagyon egyszeru: nem egyszer tortent meg, hogy csaladtagok veletlenul
>> toroltek ezt-azt egy-egy fajlbol, majd elkeseredetten hivtak, hogy most
>> akkor mi legyen. En meg szettartam a karjaimat, hogy most mar semmi. Igy 
>> meg
>> azt lehetne mondani, hogy 'menj vissza ket verziot, es ott lesz'.
>
> Korrekt, de erre is megvannak az eszkozok, az hogy ez egy fajlba keruljon
> az eredeti fajllal, olyan sulyu problema, mint hogy milyen ikonja legyen
> a backup proginak. Nem ez a lenyeg az egeszben.

Nem teljesen. Megintcsak: a legfontosabb, hogy az OS biztositja a streamek 
szoros koteset egymashoz. Nem kell kulso eszkozokkel ezt biztositani.

>> A VMS megoldasa is eleg jo, egyebkent linux alatt is bekapcsolhato ez a
>> viselkedes. A problema az, hogy nem tomorit, es nem diff-eket tarol. Azaz
>> zabalja a lemezt.
>
> A felvetett otleteid nagy resze ilyen jellegu, lemezzabalo!

Igen, ez igaz. De tortenetesen a backup/verzio management megoldas nem lenne 
az.

>> Ez megvalositas kerdese, nem szuksegszeru. Es amiota van VMM, minden
>> processz a sajat dedikalt cimtartomanyaban fut, es eleve fix cimekre van
>> linkelve, legalabbis Windows alatt.
>
> En az UAE JIT doksibol vettem az informaciokat, ha a Java is ugy mukodik,
> akkor ez nem oldhato meg. Cserebe jo gyors.

Mindig megoldhato: legfeljebb nem pont azt az image-et kell kiirni, ami a 
memoriaban fut, hanem annak valamilyen relokalhato verziojat. De mondom, 
tortenetesen 32-bites Windows alatt ez nem problema.

>> Nem, de errol nem a unicode, inkabb a lusta programozok tehetnek.
>
> Nekem az a problemam az egesszel, hogy egy csomo regi szabvanyt
> megeroszakoltak vele, es emiatt semmi sem mukodik.

Igen, es nem. A Unicode egy aranylag termeszetes kiterjesztese az ASCII-nak. 
Sokkal termeszetesebb, mint a kodlapokkal valo zsonglorkodes pl.

> Pl a vilag legnepszerubb operacios rendszere, es a vilag legnepszerubb
> filemanager programja nem jol kezeli az unicode-t.
> Ez azert eleg durva!! Az mar egyeni szoc problema, hogy az oskovulet
> amiga sem kezeli, ezert nem tudok emailezni.

A 'vilag legnepszerubb operacios rendszere' ebbol a szempontbol aranylag jo. 
Bug-ok persze mindenben vannak (meg a Microsoft termekekben is :-)), de 
alapvetoen az OS-sel, vagy meg inkabb az API keszlettel nincs baj. Az meg, 
hogy a 'vilag legnepszerubb filemanager programja' nem jo ebbol a 
szempontbol sokkal inkabb a nyugati vilag ignoranciajat mutatja, semmint a 
unicode hianyossagait. De tarthatunk egy kis kozvelemeny-kutatast:

- Ki irta a programjainak tobb mint 10%-t Unicode kompatibilisen? Jo, 
rendben, vegyuk csak a Windows/Linux-ra irt programokat.
- Ki tesztelte a programjat unicode-kompatibilitas szempontjabol? Milyen 
teszteket vegzett el?
- Ki tudja mi a kulonbseg a UTF8, UTF16, UTF32 es a Unicode kozott?
- Ki tudja hany biten tarol egy karaktert a UTF8 vagy a UTF16 vagy a UTF32 
kodolas?
- Ki tudja, mi az az OEM kodlap, es mikor van ra szukseg?
- Ki tudja, milyen kodlappal kell beolvasni egy ANSI fajlt a lemezrol, ha az 
OS koreai, a program, ami kiirta a fajlt Nemet, es a program, ami beolvassa 
Japan?
- Ki tudja, mi a kulonbseg az ASCII, az ANSI es a multibyte kodolas kozott?
- Ki tudja, melyik tavolkeleti orszagok hasznalnak Unicode, es melyek 
multibyte kodolast alapertelemezesben?
- Ki tudja, mit jelent az, hogy surrogate?
- Ki tudja, hogy a verzio-kezelo programja Unicode-kompatibilis-e?
- Ki tudja, hogy a forditoja tamogat-e unicode string-eket?
- Ki tudja, hogyan kell unicode string-eket megadni C-ben?
- Ki tudja, hogyan kell unicode escape-szekvenciakat megadni C-ben?
- Ki tudja, hogyan kell egy unicode string-et ASCII-ve alakitani, es hogy mi 
tortenik a nem reprezentalhato karakterekkel?
- Ki tanult az egyetemen/foiskolan a Unicode-rol?
- Ki tudja mekkora buffer-t kell foglalni egy 15 karaketers UTF16 
string-nek?
- Ki tudja, hogy kell megszamolni a karaktereket egy UTF8 string-ben?

A Unicode nem ott kezdodik, hogy minden karakter 16-bites, es nem is ott 
vegzodik. Sokkal inkabb szemleletmodrol, es hozzaallasrol van szo.

Persze nem kell ezekre a kerdesekre valaszolni, mindenki dontse el magaban, 
hogy o szemely szerint mit tesz azert, hogy a programok 
unicode-kompatibilisek legyenek. Oda akarok kilyukadni, hogy az emberek zome 
Europaban es Amerikaban nem is gondolkodik ezekben a fogalmakban, nem figyel 
ezekre a problemakra, nem erdeklik ezek az igenyek, igy aztan nem csoda, 
hogy az altaluk irt programok nem mukodnek jol ezek kozott a korulmenyek 
kozott. Most epp egy Magyar felhasznalo (Püski ur) akadt bele egy ilyen 
hibaba, amikor az OS Magyar volt, a fajlnev Magyar volt, a fajlkezelo pedig 
Angol.

Udv,
Tantos Andras