RE: OS windows: program komolí vlastní data, co s tím ?

[Jiri Foldyna]

Dobrý den,

nějak nerozumím tomu, proč by OS při vytváření nebo čtení binárního (diskového) souboru měl aplikovat nějaké konverze dle
nastaveného národního prostředí. To je věc programátora aplikace, nikoli OS. Naopak, OS který by mi binární soubor na disk ukládal
podle vlastní úvahy, bych považoval za špatný. U textových souborů bych možná nějakou automatickou konverzi v případě UNICODE
stringů snad překousl, ale nadšený bych z toho nebyl. Podle vašeho popisu se domnívám, že programátor jednoduše odflákl čtení a
zápis přes streamy, a že ve Wine to chodilo spíš omylem, tedy díky ne zcela dodělané podpoře locales ;-). S VB jsem naštěstí nikdy
nemusel pracovat, ale odhadl bych to na nějakou ne zcela správně pochopenou práci se streamy, právě kvůli tomu, že chyba byla
způsobena nastavením decimal separator. Kdyby se jednalo u čistou binárku, byl by float uložen s největší pravděpodobností jako
single nebo double, tedy 4 nebo 8 byte v souboru, takže decimal separator by nehrál žádnou roli. OS Windows bych v tomto případě za
viníka nepovažoval, blb dokáže napáchat chyby v libovolném OS :-D

JF

> Zdravím,
>   tohle moje "šťourání" opravdu není myšleno jako snaha o
> vyvolání flamewaru.
> Věřte nebo nevěřte, já se skutečně upřímně ptám.
>   V Unixových operačních systémech totiž nevím o tom, že bych
> něco podobného
> musel pro ukládání dat dělat.
>   Vezměme např. funkci *printf(), která by nejspíše byla použita pro
> formátování desetinného čísla. Cituji popis specifikátoru %f:
> " The double argument is rounded and converted to decimal
> notation in the
> style [-]ddd.ddd, where the number of digits after the
> decimal-point character
> is equal to  the  precision  specification.". Vidíme tedy, že
> národní nastavení
> se zde neuplatňuje. Chci-li používat národního I/O, musím si
> před tím volat
> speciální konverzní funkce.
>   Obdobně zase funkce čtení *scanf() umí přečíst desetinná
> čísla s tečkou a
> ne jiná.
>   Čemu v případě tohoto programu nerozumím, je:
>   1) Proč se uplatňují národní nastavení i v takovém druhu
> I/O, které vytváří
> čistě binární soubor ? Vždyť tam můžou nastat jen chyby a
> nikdy to nemůže být
> k ničemu dobré! Dle mého názoru by mělo být standardní I/O
> bez národních
> konverzí a pokud jsou třeba, tak volat taky přes nějakou
> konverzní funkci.
>   2) Proč by případně autor záměrně volal tyto funkce, když
> jeho cílem je
> skutečně jen binární datový soubor ?
> Abych si alespoň sám na tyto otázky částečně odpověděl,
> zkusil jsem zjistit,
> v čem že je ten program vlastně napsán. V jeho bináru jsem
> našel tento string:
> D:\Program Files\Microsoft Visual Studio\VB98\VB6.OLB
> Znamená to, že ten program je psán ve Visual Basicu ? Hmm,
> tak ten zase
> vůbec neznám. Zohledňují tam automaticky operace I/O
> nastavení národního
> prostředí ? Musí se to napřed vypínat, nebo naopak zapínat ?
> Asi moc otázek,
> že ? No nic, nechme toho.
>   Řešení se našlo a to je hlavní. Nyní mohu definovat všech
> 128 kanálů a
> kolega tam nebude muset zadávat subtóny ručně :-). A proč to
> nefunguje, to
> necháme koňovi, ten má větší hlavu.
>   Zdraví Pavel.
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>