Citat:
Nedeljko
Dakle, MS-ovo rešenje sa WCHAR ne rešava problem, nego ga čak i produbljuje - postojeće greške se ne ispoljavaju.
To sam pokusao da ti kazem. Kad pogledas celu tu sagu:
1. Windows 1.x je bio ANSI i sve je bilo dobro (u UK i USA). Haha, zaje*avam se naravno, cuj "sve je bilo dobro" :-)
- Windows ANSI zapravo >nije< ANSI tj. poceo je kao ECMA-94 ali je nastavio svojim putem, dok je ECMA-94 postao ISO 8859-1 a kasnije Unicode
- Microsoft, uvek raspolozen za pravljenje haosa je postigao da Windows i DOS nemaju isti karakter set, cak i pre Windows-a 3.x
2. Windows 2.0 i 3.0 su poceli da menjaju ANSI karakter set dodavajuci nove karaktere (IBM Codepage 1004 - Latin-1 Extended)
3. Windows NT 3.1 - NT 4.0 su bili UCS-2 i ANSI u isto vreme (MessageBoxW i MessageBoxA), kao Dr. Jekyll & Mr. Hyde; Ovo je momenat kada je seme hao.. kupusa posejano.
4. Windows 3.1 - Win 95, kao i NT 4.0 su dodali nove karaktere - ovo se ponekad zvalo CP 1007 (huh?)
5. Microsoft je preimenovao ovu kodnu stranu u poznatu CP 1252 prilikom izbacivanja Windows 95 i Windows NT 4.0; Win32 API u Windows 95 nije imao Unicode podrsku
U ovom periodu (Windows 3.1 - 95), na scenu stupaju razne medjunarodne kodne stranice, koje cesto nisu standardne i podlozne su promeni. Drugim recima, haos. Ako vas ne-engleski jezik koristi jednu stranicu, na konju ste :-) Kako je Windows 95 dominantan korisnicki OS u odnosu na NT, Unicode je daleko manje bitan, svet je prakticno ANSI ili CPxxxx
- Windows 3.1 pojma o kodnim stranama nije imao. Morao si build-ovati ceo OS za neki jezik
- Windows 95 je imao CP podrsku, ali na zalbe Amera je engleska verzija imala samo 1252 (Ameri se zalili na bacanje prostora)
- NT 4.0 je imao vecinu sa nekim izuzetcima. Unicode mislim da niko osim MSFT-a nije koristio.
- 1998 je izdat "euro" update NT 4.0 sa doradjenim kodnim stranama
- Iste 1998 je izasao, naravno, Windows 98 :-) Ovog puta ostvarujuci paritet sa NT-om, zato sto su Ameri dobili vece diskove, pa nije vise bilo razloga da se bune
- 2000-te je izasao Windows 2000, koji je baziran na NT arhitekturi. Microsoft prelazi sa UCS-2 na UTF-16 bez da promeni API-je i promptno zase*avaju NTFS imena, ceo svet mora da se prilagodi i izmisli WTF-8 kodiranje. Windows 2000 je podrzavao ANSI - ovo je bio najbolji momenat da se uvede UTF-8, ali je Microsoft suvise bio zauzet stavljanjem imena .NET na sve
- 2001-ve izlazi Windows XP, koji ima istu podrsku za pisma kao Windows 2000... pocinje vreme sporog ali sigurnog prelaska na "MSFT Unicode" od strane app vendora
- Windows ME... salio sam se :)
...
- Negde u medjuvremenu (nemam pojma kad tacno), Microsoft krece polako "ispod zita" da uvodi UTF-8, ali u strogo ogranicenim kolicinama
- 2018-me godine, Microsoft konacno izbacuje Windows 10 preview sa "beta" opcijom prelaska celog OS-a na UTF-8 (sto se postize specijalnom kodnom stranom: 65001)
...
E, sad, Nedeljko - Win32 je, prakticno, aktivan od 1993-ce (1990/1991 u alpha/beta varijanti), ali je kompletno nasledio Win16 i sva s*anja.
Ne mozemo zameriti MSFT-u na sve ANSI hackove do pojave Unicode-a. Takodje, ne mozemo zameriti Microsoftu sto je izbacio NT OS prakticno u isto vreme kao prva rana verzija UTF-8, sto znaci da nije bilo sanse da im se ukrste putevi razvoja. Plus, u tom momentu (1992-1993) UCS-2 je bio "sinonim" za Unicode.
Prvu sansu da poprave stvar su u Microsoftu dobili sa Windows 2000, posto su vec bacali UCS-2 u djubre, mogli su komotno da uvedu UTF-8. Ali to bi bilo drasticno teze, ponajvise za sam Microsoft a onda i za app vendore cije ANSI aplikacije cesto ni u ludilu ne bi mogle da se nose sa UTF-8. Realnost je da Microsoft nije ni imao previse izbora tu.
Zbog svega ovoga, Windows kod je prakticno miks ANSI stringova (rani Win32, i dalje gomila konzolnih i sistemskih stvari koje nemaju UI), nekih kvazi UTF-16 (u manjem ili vecem skladu sa UTF-16 a ne UCS-2), WTF-8 u OS kodu i, naravno, novih UTF-8 stvari. wchar_t im je 16-bitni za razliku od Linux-a gde je 32-bitni... i taaako.
Mislim da je adekvatan termin za to:
kupus :-)
Bonus materijal:
Citat:
Microsoft's compilers often fail at producing UTF-8 string constants from UTF-8 source files. The most reliable method is to turn off UNICODE, not mark the input file as being UTF-8 (i.e. do not use a BOM), and arrange the string constants to have the UTF-8 bytes. If a BOM was added, a Microsoft compiler will interpret the strings as UTF-8, convert them to UTF-16, then convert them back into the current locale, thus destroying the UTF-8.[15] Without a BOM and using a single-byte locale, Microsoft compilers will leave the bytes in a quoted string unchanged.
Citat:
Bush hid the facts is a common name for a bug present in some versions of Microsoft Windows, which causes text encoded in ASCII to be interpreted as if it were UTF-16LE, resulting in garbled text. When the string "Bush hid the facts", without newline or quotes, was put in a new Notepad document and saved, closed, and reopened, the nonsensical sequence of Chinese characters "畂桳栠摩琠敨映捡獴" would appear instead.
...
The bug occurs when the string is passed to the Win32 charset detection function IsTextUnicode. IsTextUnicode sees that the bytes match the UTF-16LE encoding of valid (if nonsensical) Chinese Unicode characters, concludes that the text is valid UTF-16LE Chinese and returns true, and the application then incorrectly interprets the text as UTF-16LE.[2]
I tako... kad ce sarma?
DigiCortex (ex. SpikeFun) - Cortical Neural Network Simulator:
http://www.digicortex.net/node/1 Videos:
http://www.digicortex.net/node/17 Gallery:
http://www.digicortex.net/node/25
PowerMonkey - Redyce CPU Power Waste and gain performance! -
https://github.com/psyq321/PowerMonkey