Evo ti za UTF-16:

Hvala! Ovo radi. Naravno, unicode literale pišem sa prefiksom "L", odnosno kao

L"Kako se zoveš? "

Ako se koristi MinGW kompajler, onda linkeru treba zadati -municode. Za MSVC i LLVM ne treba.

Uzgred, ovo je samo polovicno resenje - na zalost, Windows konzola i dalje (koliko znam) ne podrzava unos podataka koje pokriva UTF-8 komplet (probaj sa nekim "Emoji"-ma) i sl, pa cak i insistiranje na UTF-8 i eksplicidno podesavanje konzolne kodne strane nece resiti problem.

Ovaj polovicni UTF-16 donekle resava problem bar kada su 'nasi' karakteri u pitanju, ali puno srece sa necim egzoticnijim.

Ima Character Map sa kojim moze da se vidi koje karaktere podrzava izabrani font.
WIN 10 u konzoli ima Consolas font, kao default.

Ne vredi font nista, jednostavno console host ne podrzava komplet UTF-8 kao ulaz:

https://github.com/vezel-dev/cathode/issues/68

PowerShell i WSL (naravno) ne pate od toga, ali Win32 konzola je i dalje falicna. Probaj da uneses npr 🎁 - cak ni chcp 65001 ne pomaze.

Dobro, nisam napisao da se sa Character Map mogu videti utf-8, nego da se mogu videti karakteri koje ima taj font.

To je OK, ali sve i da font ima karaktere (ima), Windows Console Host ti ih nece dati kao input.

Eksperiment, startuj PowerShell - ukucaj 🎁, moze.

Onda startuj tvoju konzolnu aplikaciju koja prima ulaz sa konzole, sve i da je nastelovana UTF-8 kodna strana, ulaz ce biti - djubre.

Ako probam paste u PS daje dva znaka pitanja.

Kad se pogleda u properties vidi se da imam 852 (OEM - Latin 1) i u PS i u konzoli.

Ako moze PS da prikaza taj znak onda moze jer koristi neku drugu kodnu stranu.

Namesti UTF-8 - vidim da imas Windows 8, mislim da je to tad bilo jos eksperimentalno, negde u regional settings.



U Windows konzoli:



Ili programski: SetConsoleOutputCP(CP_UTF8);

Ali, kao sto rekoh, to utice samo na izlaz, ne na ulaz.

Kad se promeni kodna strana PS sa paste i dalje daje znak pitanja.

Inace win 8 prijaljuje IE web komponenta koju koristim a koristim u win 10.

Mislim da su tek od nekog Win10 builda ukljucili to a da ne bude eksperimentalno - ako ti bas treba UTF-8 u PS-u probaj na Google-u da nadjes kako da se ukljuci.

chcp radi samo za console host (command prompt) - i to samo za ispis ako nekako uspes da mu poturis UTF-8 bafer (nece ici preko clipboarda).

Posle chcp 65001 U PS kaze da je UTF-8 kodna strana.

Inace sam ja ranije radio sa kodnim stranama a sada se samo prisecam.

https://helpcenter.nshift.com/...dows-10-Unicode-UTF-8-encoding



E sad ne znam koliko je to bilo 'mature' u Win10... mada na tome su radili 10+ godina.

Na zalost, kad je klasicna konzola u pitanju, ocigledno ne jos zadovoljavajuce. Mada nije da ih ne razumem, sama tema je komplikovana + Win32 API je osinje gnezdo sto se toga tice (imali smo vec temu o tome, istorija je dugacka i na zalost ucinjeno je par gresaka u dizajnu koje je jako tesko ispraviti ako se zeli ocuvati kompatibilnost).

Mada, opet, novi terminal je kud i kamo bolji... ali iskreno, od kad postoji WSL2, pogotovu na Win11 gde je jako dobro i graficki integrisan, mislim... kome jos Win32 konzola treba, kad imas native bash ili koji god Linux shell zelis.

Meni je bitno da moj program bude OK. Ako MS-ov nije OK, to nije do mene. Dakle, ako radi savršeno sa savršenom konzolom, onda sam ja zadovoljan.

Jedno od rešenja je da isporučiš korisniku svoju konzolu. Osnovnu konzolu nije teško napraviti.

Nije bitno ali cini mi se da je Dimkovic pomesao mene sa pokretacem teme :)

Da dodam (ne zbog sebe nego zbog teme) da sam poceo da programiram kad je postojao samo DOS operativni sistem.
DOS je imao mogucnost grafike na nacin da se koriste karakteri iste velicine.
Zbog toga konzola koristi odredjen skup fontova koji imaju istu velicinu karaktera.

Zato to nije mana nego jednostavno pravilo koje je ostalo od DOS-a.

Pricas o monospace fontovima, ali ne vidim kakve veze monospace fontovi imaju sa Nedeljkovim pitanjem koje se tice Unicode podrske.

Monospace fontovi savrseno podrzavaju Unicode karaktere.

Pre izvesnog vremena sam napiao C programče za "šišanje" latinice, odnosno fajl u 1250 kodnom rasporedu sam morao da očistim od naših znakova.

Naravno, napisao dotični program na Linuxu, testirao, pa onda kompajlirao migw-om za Win. Kaspersky na to vrisne da mi exe ima virus, pa ja šta ću, skinem Pelles C da njime kompajliram Win verziju.
Ispade, program radi i na Win ali pravi duplo veći fajl. Iz nekog razloga, Win smatra da mora da upiše karaktere kao UTF-16. Morao sam da izmenim program da čita i piše fajl u binary modu.

Da čovek poludi sa Windowsovim kerefekama. Na normalnim operativnim sistemima fajl je stream of bytes, a Win mora da zabiberi neko svoje tumačenje...

Visual Studio vec duze vreme podrzava Clang, unutar samog IDE-a - preporucio bih to kao resenje umesto mingw-a.

Win32 API, bar u poslednjih par godina (Windows 10 1903 i kasnije), podrzava UTF-8 u ANSI verzijama API-ja (xxxA pozivi) - ogranicenje je konzolni podsistem koji i dalje nije u stanju da cita stdin u propisnom UTF-8 formatu, ali citanje / pisanje fajlova nije problem.

Stavi ovo kao .exe manifest da ne bi bilo problema:



Naravno, ako koristis Win32 API-je, aplikaciju kompajliras kao ANSI, u suprotnom je default "wide char" API (xxxW).

Vise detalja: https://learn.microsoft.com/en...globalizing/use-utf8-code-page

Mislim da MSVC kompajler ima /utf-8 opciju da uradi posao za tebe, mada ne koristim doticni kompajler godinama pa nisam koristio tu opciju.

https://learn.microsoft.com/en...er-sets-to-utf-8?view=msvc-170

+ Ako ciljna grupa koristi Windows 10 i ima kontrolu nad instaliranim opcijama, mozes jednostavno da ostanes u Linux okruzenju a na Windowsu izvrsavas proces iz WSL konzole. WSL2 je cist Linux pa nemas problem sa kompatibilnoscu. Ja se vise uopste ne zamaram kompajliranjem npr. OSS stvari u Win32 (osim ako eksplicitno ne podrzavaju Win32), daleko je jednostavnije i brze otvoriti WSL2 shell i poterati make.

Nisam mogao da koristim VS comunity verziju zbog licencnih ograničenja (broj zaposlenih i ukupan prihod), a nije baš da bi firma platila licencu za programče od 25 linija.

Trebalo bi sve da radi i iz MinGW okruzenja, mozda ces morati manuelno da linkujes manifest, ali sve ostalo vazi - koristi ANSI verzije Win32 API-ja i ne bi trebalo da imas problem (osim ako ne citas iz stdin-a) ako je setovana UTF-8 kodna strana.

Primer 🎁 koji se kuca sa alt+127873 imaju fontovi "Segoe UI Emoji" i "Segoe UI Symbol".
Ovi fontovi nisu monospace i nisu na listi za izbor u konzoli a ni PS.

Svi drugi karakteri koji imaju izbarani monospace font mogu da se koriste i kao unikod.

https://stackoverflow.com/ques...ompt-windows-powershell-window



https://stackoverflow.com/ques...ows-command-line/388500#388500

Ivan je u pravu u vezi razdvajanja ovih stvari od fontova.

Ono što se u C-u zapisuje kao stdin, stdout i stderr su objekti u memoriji, pri čemu svako proces ima svoje stdin, stdout i stderr, i koji nisu vidljivi na ekranu.

Ako proces P napravi proces C, onda je proces P roditelj procesa C, a proces C je dete procesa P. U tom slučaju, proces P može da upiše nešto u stdin procesa C, kao i da očitava stdout i stderr procesa C.

Konzola ili terminal, kao što je na Windows-u Command Prompt (cmd.exe) je program koji ima nekakav korisnički interfejs i nudi korisniku mogućnost da izdajen neke komade koje konzola izvršava.

Pritom, korisnik može da izda, na primer, komandu za pokretanje nekog procesa sa nekim argumentima. U tom slučaju, konzola pravi odgovarajući proces (Win32 API funkcija koju konzola kao program poziva je PrecessCreate). Pošto je to dete proces od konzole, konzola može da mu unos od korisnika prosledi na stdin, kao i da očitava njegove stdout i stderr i da taj izlaz prikazuje korisniku.

Taj korisnički interfejs (za unos od strane korisnika i prikazivanje korisniku) zahteva neke fontove, ali oni nemaju veze sa pojmovima standardnog ulaza (stdin), standardnog izlaza (stdout) i izlaza za greške (stderr).

Ukoliko konzola iz bilo kog razloga ne podržava slanje nekih znakova procesu, stdin procesa to neće dobiti bez obzira na fontove.

Isto tako se može koristiti i preusmeravanje (redirection) nekog fajla u stdin, kao i preusmeravanje stdout odnosno stderr u neki fajl. Ovo poslednje uz brisanje tog fajla na početku ili uz dodavanje na kraj zatečenog sadržava fajla, a prema izboru korisnika (da li je otkucao > ili >>).

Takođe, moguće je i pokretanje više procesa u cevi (pipe), pri čemu konzola prosleđuje sadržaj (prihvaen od strane korisnika ili iz fajla) na stdin prvog procesa u nizu i očitava stdout i stderr od poslednjeg procesa u nizu (koji prikazuje korisniku ili preusmerava u fajl). U tom slučaju je svakom procesu u nizu, sa izuzetkom prvog, stdin jednak stdout-u prethodnog procesa u nizu.

Konzola se obično odnosi na nekakvu ljusku, odnosno skript jezik koji omogućava i ovakve komande.

Najjedostavniji nacin da se proveri sta prikazuje je preimenovanje nekog direktorijuma (foldera).
Sa dir u comandnoj liniji se moze videti sta prikazuje a sta ne.

Nadam se da Ivan nece nastaviti da daje savete :) a mene je interesovalo ima li nesto novo i propustam li nesto.
Citati koje je stavio Ivan su mi dovoljni i hvala mu na tome.

Ehm, postoji poseban problem sa ulazom a ne (samo) sa prikazivanjem. To je vise problema, ne jedan.

Sumnjam da ce MS to popraviti, oni su i ovako i onako fokusirani na PowerShell a sada kada je WSL2 integralni deo Windows-a, ljudima sa specificnim potrebama je i ovako i onako lakse da te stvari implementiraju u Linuxu koji je sad vise nego dobro podrzan unutar samog Windowsa.

Nedeljko je napisao da je Ivan u pravu a nije se izjasnio oko WSL.
Inace ja vec koristim ubuntu u wmware.

Ovo sam dodao da neko ne pomisli (ako je to bitno uopste) da sam samo za Windows.

VMWare je OK, ali posto je Windows od skora i u desktop verzijama virtualizovan tj. dolazi sa Hyper-V particijom i ovako i onako (HVCI - Hypervisor-Protected Code Integrity), manji je overhead startovati jos neku Hyper-V masinu nego 'nested' virtualizacija sa VMWare-om onda.

WSL2 koristi nesto sto oni zovu "lightweight" virtuelna masina (verovatno osisana od nekih nepotrebnih stvari) - trebalo bi da se startuje jos brze od "pune" Hyper-V masine.

Na zalost, to sa sobom nosi i neka ogranicenja - npr. WSL2 ne vidi vise od 64 procesorska jezgra i jednog fizickog socket-a, cak i ako rekompajlirate kernel sa drugim max parametrima. Verovatno je vezano za tu "lightweight" konfiguraciju. Ko hoce vise, ne gine pun VM.

WSL slabo radi. Koristio sam, ali džaba. Radije bih koristio Linux u virtuelci. Nije do performansi, nego do mogućnosti. Probaj da instaliraš na primer kate. Takođe, gde su KDE džidža-bidže?

_{[Ovu poruku je menjao Nedeljko dana 27.08.2023. u 21:49 GMT+1]}

Koliko se sećam nekog tutorijala u kome se koristi konzola (powershell i druge), autor je napomenuo da standardna Win konzola (cmd.exe) ne podržava neke stvari zbog kompatibilnosti unazad, ali kada se sa Win Store skine isti taj CMD, onda podržava neke stvari kojih nema u onom koji dođe uz standardnu Win instalaciju.
Međutim, ja nigde nisam video tu verziju Windows CMD, samo npr. Windows Terminal, što nije isto, jer on koristi Powershell ili CMD da omogući više konzolnih prozora u tabovima i sl.

Uglavnom, mislim da je kod Win i dalje UTF-16 podrazumevan interno kod sistemskih aplikacija, verovatno im nije problem da to promene u UTF-8, ali ne žele zbog - naravno, zbog kompatibilnosti unazad.

Windows (NT) Kernel API je od samog starta "wide char" i generalno indiferentan na encoding posto jako malo operacija uopste zavisi od toga. Ne treba gubiti iz vida da je sam Windows kernel API (ilI NT OS/2 API kako se zvao u pocetku) stariji od Unicode-a. Srecom, u kernel svetu gde zivi dosta drajvera to nije vazno posto generalno vecina sistemskih poziva radi sa baferima i ne zanima ih previse njihov sastav. Fajl sistemi su druga prica i tu ima zackoljica*

Userland API tj. Win32 API je na NT-u uvek imao 2 varijante: "Wide char" koji se cesto nazivaju "Unicode" (vrlo neprecizno) verzije - tipa CreateWindowW, i ANSI verzije tipa CreateWindowA koje su takodje mogle da 'razumeju' lokalizaciju setovanjem odgovarajuce kodne strane.

Microsoft je dosta vremena radio na UTF-8 'kodnoj strani' (65001) koja je u Win 10 1903 konacno izasla iz bete - kada Win32 "ANSI" aplikacija ima UTF-8 kodnu stranu, to signalizira OS API-ju da aplikacija koristi UTF-8.

(*) Ali... to nije cela prica. Cela prica je drasticno komplikovanija i prevazilazi okvire ove teme, za pocetak: imena fajlova koja nisu bila kompletno UTF-16 kompatibilna (Microsoft-ov tretman je imao i ime WTF-8 - https://simonsapin.github.io/wtf-8/) i koja su posledica odluka donesenih kasnih 90-tih. Novije verzije Windowsa ne dozvoljavaju neke stvari koje su bile "legalne" u ranijim revizijama tipa NT4, ali to nije garancija da neko nece naleteti na fajl sisteme kreirane sa tim verzijama OS-a. Ogranicenja konzole u pogledu ulaza su jos jedan primer.

--

Linux je imao drugaciju istoriju, ali kao sto rekoh, pocetne verzije onoga sto je postalo Windows NT su starije od Unicode-a, i sam NT je bio medju ranim OS-evima koji su implementirali Unicode (prvo UCS-2, a kasnije UTF-16) - pre nastanka UTF-8.

Mozda postoji Linux koji bi u WSL radio isto ili samo ono sto radi cmd a da ima i utf-8.

Postoji ovo:

Until and including version 20.04 LTS there is (was) also the Ubuntu mini.iso that could install a minimal command-line system.

Po defaultu, WSL2 distribucije su 'minimalne' u smislu da ne dolaze sa grafickim okruzenjima i sl. - prakticno shell jeste default.

Evo sta je trenutno dostupno na Windows Store-u:



Moguce je dodati i druge rucno, ima tutoriala kako.

Da, stvarno, kate radi i kod mene, "samo" što mu treba 25 sekundi da se pokrene.

Evo ovo kao dopuna:

DOSBox-X 0.83.21 Release Notes

Support for viewing Unicode (UTF-8 or UTF-16) documents in the shell

DOSBox-X now supports UTF8 and UTF16 commands, which allow to convert UTF-8 and UTF-16 encoded text to view in the current code page, including both SBCS and DBCS code pages. For example, the command “UTF8 < UTF8TEXT.TXT” will output converted text UTF8TEXT.TXT in the current code page, and for UTF16 command there are optional /BE & /LE options to specify endianness.

@Nedeljko,

Kasnjenje verovatno dolazi zbog startovanja grafickog podsistema (mada, kod mene se kate startuje prvi put za ~3s, posle toga za ~1.5s sto je ipak drasticno bolje od neprihvatljivih 25s, bilo bi interesantno videti zasto mu toliko treba na tvojoj masini), sam WSL2 je zadovoljavajuce brz (https://www.phoronix.com/review/windows11-wsl2-good) - za konzolne stvari je odlican kao i za npr. CUDA testiranje u domenima gde je Linux dominantna platforma (naucne i HPC npr.).

Bar meni, najveca ogranicenja su vezana za samu WSL2 virtuelnu masinu (ne vidi vise od 1 fizickog CPU socketa, ne vise od 64 CPU jezgra i nije u stanju da napravi vNUMA konfiguraciju) - verujem da moze da se konfigurise da iz prve startuje X i ubrza startovanje grafickih aplikacija ali ove druge limitacije ostaju.

Glavni 'use case' je za korisnike koji primarno rade iz Windows-a ali im treba i Linux (za vec pomenute naucne / HPC aplikacije recimo) ili jako dobro integrisan sa Windows radom ili se zahteva GPU akceleracija u Linuxu u isto vreme u kom slucaju je integracija jako dobra ako je u pitanju NVIDIA i bolja od obrnute varijante gde bi Linux sa KVM-om bio glavni OS - za potpunu hw.-ubrzanu grafiku je u tom slucaju neophodno uraditi kompletan GPU "passthrough" u KVM-u sto GPU cini onda nedostupnim u samom Linuxu.

Za ostalo, YMMV.

Inace, ako ste kupili neki relativno novi laptop koji dolazi sa Windows 11 OS-om, velike su sanse da je "iz fabrike" konfigurisan da trci u hipervizoru (OS koristi specijalnu particiju za dodatni nivo zastite) - u kom slucaju je WSL2 "besplatan" u kontekstu performansi (jos jedan HV "gost"), cak nije potrebna ni instalacija celog Hyper-V okruzenja posto je MS izdvojio neophodne komponente kao deo samog OS-a i "Virtual Machine Platform" opcioni feature koji je neophodan za WSL2. Da li je to slucaj se moze proveriti sa npr. HWInfo-om koji ce na glavnom ekranu to prijaviti:



Takodje, WSL2 virtuelne masine koriste dinamicku memoriju - sto znaci da nece "zauzeti" neku fiksnu kolicinu i 'uzeti' je od drugih OS-eva permanentno.

Kod mene uvek 23 sekunde.

Upalim ununtu WSL2 na Win11.

Upalim kate, 23s.
Ugasim kate (WSL2 ostane upaljen) i pokrenem kate, pokretanje traje 23s.


Ugasim kate (WSL2 je i dalje upaljen).
Upalim kate sa "kate &" tako da mogu da kucam u konzoli dok je kate upaljen - 23s.
Upalim drugi kate pored tog prvog - 23s.

Zanimljivo, da li isto vazi za bilo sta graficko, tipa gedit?

Deluje kao neki wait/timeout negde. Koja masina je u pitanju (CPU, disk, memorija)?

Ne. KWrite se pali brzo, kao i gedit.

gedit koristi druge biblioteke, dok su kate i kwrite iz KDE paketa. Jedino što kate koristi KParts, da bi imao integrisan Konsole dodatak.

Mašina:

16 GB LPDIM RAM, AMD Ryzen 7 5800U sa 16 fizičkih jezgara, 1TB SSD...

Bas cudan problem, svakako ne bi trebalo da se desava... takva kasnjenja obicno uvek impliciraju neki file I/O, ali verovatno bi bio prevelik cim gledati sta je tacno problem (da li je u samom distro-u ili nesto drugo).

Da li ima nesto cudno u kernel msg. baferu tipa timeout ili nesto slicno?

Prilažam izlaz iz dmesg.

Ovo je bio nakon podizanja sistema, a sad šaljem dmesg nakon paljenja i gašenja kate.

Imao sam situaciju da je neki softver imao pauzu od 30s prilikom pokretanja. Debuger je otkrio da je programer zaboravio sleep 30 u kodu, kada je pustio build, pa su ispravili u sledećem peču.
Da probaš da uradiš update paketa?

Je li znas sta je ovo @Nedeljko:



Signal 6 je SIGABRT - nesto definitivno puca.

Koliko korisniku treba da puca za to šta i zašto nešto puca? Je li to onaj svemogući WSL2?

Evo me na ubuntu-u 20.04. Kate se pali za 1s.

Ma ok, pitao sam samo iz znatizelje, ako ti puca za to, to je skroz u redu.

Onaj prvi dmesg.txt je posle dizanja WSL-a i ima 491 poruku. Onaj drugi je posle paljenja kate i ima pucanje u 492-goj poruci. Dakle, to je.

kactivitymanage proces krahira iz nekog razloga, pretpostavljam da je kasnjenje zbog cekanja i isteka timeout-a na sta-god-se-ocekuje od tog procesa.

Ako te ne mrzi, da li mozes da vidis sta gdb daje kao stack trace? Mislim ako ti nije cim, cisto razumevanja sta se desava radi.

Pretpostavljam da si mislio na ovo:



I šta bi? Pravi li WSL2 coredump i gde ga smešta?

Probaj ovo ca tim crash.cpp:



Da li ovo radi?

U prilogu šaljem rezultat od