Aktualizováno 01.01.18 12:56:17
*********************
02.01.2018
Aktualizována dokumentace a v posledním stavu wr586 je změněn dosavadní odkaz
z dokumentace pro WR585 na dokumentaci k WR586.
********************
06.12.2017
Užitím výše uvedených příkazů můzeme dostat seznam tiskáren v Win7:

.onerr #; .getkey hodn,"HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/ProfileList!"
.if(error) .exit
.test $net
.test $username
del=$strlen-1
.do(hodn)
.parse hodn,";",u,hodn
.onerr #; .getkey hod,"HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/ProfileList/'u'=ProfileImagePath"
.if(hod[1:*-1]=="C:\\Users\\'$username'") .break
.end_do
.onerr #; .getkey hodn,"HKEY_USERS/'u'/Software/Microsoft/Windows NT/CurrentVersion/Devices#"
!.bigmen(6,r1|mh|rm:1,-1,-1,16,1000,"Zvol tiskárnu","ESC nic")
.do(hodn)
.parse hodn,";",t,hodn
;'t'
.end_do
.asks pr Zvol tiskárnu
;'pr'

Nevím, zda je to univerzální pro vyšší Windows. Prověřím to.
********************
16.11.2017
Konvertovat soubory v UTF8 a UTF16 umí PIP tam a zpátky. Jinde např. q5:81 nefunguje.
U instrukce CSV je to ale zbytečně nefunkční. Takže nyní připuštěno v CSV i q5:8x a q5:9x.
x=1,2,3,5,6
*******************
Užitím výše uvedených příkazů můzeme dostat seznam tiskáren v WinXP:

.onerr #; .getkey hodn,"HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/ProfileList!"
.if(error) .exit
.test $net
.test $username
del=$strlen-1
.do(hodn)
.parse hodn,";",u,hodn
.test u
.if($strlen<del) .continue
.if(u[*-del:*]==$username) .break
.end_do
.onerr #; .getkey hodn,"HKEY_USERS/'u'/Software/Microsoft/Windows NT/CurrentVersion/Devices#"
.if(error) .exit
!.bigmen(6,r1|mh|rm:1,-1,-1,16,1000,"Zvol tiskárnu","ESC nic")
.do(hodn)
.parse hodn,";",t,hodn
;'t'
.end_do
.asks pr Zvol tiskárnu
;'pr'
*******************
15.11.2017
Potřeboval jsem při zkoumání systémového registru zjistit seznam poduzlů
uzlu a seznam jmen hodnot uzlu. Přidělal jsem to do .getkey. Možná, že
se to může někomu hodit.

.getkey hodn,"HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/ProfileList!"
;'hodn'
.;dostaneme seznam uzlů oddělených středníky
.parse hodn,";",u1,u
.getkey hodn,"HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/ProfileList/'u1'#"
;'hodn'
.;dostaneme seznam jmen hodnot v prvním uzlu
********************
07.11.2017
Přidána numerická funkce txnb(<text>) převádějící <text> na číslo. Na začátku
převodu se v textu vynechají všechny znaky různé od 0-9, tečka, mínus a čárka.
Čárka se převede na tečku. Takže např:

m:="1 237 "
n=txnb(m) !dá 1237

m:=" -12.1"
n=txnb(m) !dá -12.1

m:="xxx-12,1xx"
n=txnb(m) !dá -12.1

Funguje přirozně jak v ATP tak v aritmetickém bloku instrukcí. <text> je
buď textová konstanta nebo textová proměná ATP a v instrukci textová položka.

V ATP se např. dosud musilo:

m:="1 237 "
m:=rp(m," ","",1)
n='m'

ale

m:="1 237x"
m:=rp(m," ","",1)
n='m' !zhavarovalo
n=txnb(m) !dá 1237

********************
06.11.2017
V instrukci CSV, která vznikla z instukce ZUZ zůstala pro přepínač MX
povinnost uvést druhou podmínku na výstup. Protože to chybělo v popisu
a působilo to tak potíže, tuto povinnost jsem zrušil.

Dále nadále je odlišné re[:1] a re:2. Zatím re:1 a re:2 převedlo všechno
na řetězce RE/RV, pak re:2 nepoužilo RV. Nyní re:2 běží jako bez re, ale nepoužije RV.
Pokud by chtěl někdo použít původní re:2, je nutno dát re:3.

V informačním menu WR - "Parametry tisku" byla omezena (deklarací) délka
jména tiskárny - nyní může být libovolná.
********************
26.10.2017
Konstatuji, že pokud se nanajde prn5w nebo použijete .setlpt ..., pak jsou až
do příkazu .setprn xxx, nefunkční příkazy .setprnd a .setprns. Je to vlastně
O.K., protože bez ovladače prn5w, nelze zajistit WIN tisk.
********************
18.10.2017
Ve spolupráci s ing. Balášem jsem odstranil některé problémy
a doplnil některé funkce při užití GRD v grdwin okně.
********************
17.10.2017
LST generovalo sestavy s obrázky v režimu SP nebo PF s absolutními adresami.
Z toho vyplývalo, že poukd se dvě sestavy spojily PIP /ap, výsledek byl
nefunkční. Proto jsem absolutní adresaci nahradil relativní a pak spojení
je funkční.
*******************
16.09.2017
Na základě výzkumu ing. Havla v oblasti EPO (elektroniké podání formulářů)
byla do .crypt_signmessage doplněna možnost zahrnutí podepisovaného dokumentu
do výsledné zprávy:

.CRYPT_SIGNMESSAGE "DPH1.XML","hh","DPH1.sgn+"

dosáhneme toho příznakem + za výstupním souborem.

Dále .readhttps metodou GET předpokládalo textový a ne binární obsah předávaného
souboru, což podepsaný dokument nesplňuje. Takže místo pouhého ! pro GET je
možno uvést !b indikující, že soubor je binární.

Takže podání lze např. otestovat příkazy:

.crypt_signmessage "DPH.XML","<fragment jména certifikátu>","DPH.sgn+"
.readhttps "adisepo.mfcr.cz","adistc/epo_podani?test=1"!b"DPH.sgn","ODP.xml"
*******************
25.08.2017
V GRD nyní funguje redapovská podmínka q0 x1,x2,x3... Problém byl v tom, že se
interně volá instrukce IND, u které bylo zakázano aktualizovat číslo věty.
*******************
06.08.2017
Redap má odjakživa ošetření pouze pravděpodobných chyb. Pokud bych důsledně
ošetřil jakékoliv porušení interních struktur, narostl by kód minimálně na dvojnásobek.
Proto v případě narušení hlavičky RDA virem, WR upadl. Ošetření všech možných
poškození hlavičky RDA, by bylo značně náročné. Proto jsem zavedl KS záhlaví
RDA díky existenci položky typ RDA v záhlaví RDA a rezervaci místa pro budoucí
časy. Nicméně je zřejmé, že pokud RDA znovu nevytvoříte, KS v záhlaví nebude.
Nyní pro nové RDA by se vypsalo

432 Hlavička RDA je poškozena

a zpracování hlavičky je přerušeno.
*******************
30.06.2017
Detekce fragmentu věty na konci RDA vede na chybu 431 a je od 21.6.2017. RDA lze
napravit pomocí ZUZ s přepínačem ks:2.
*******************
29.06.2017
Ukázalo se po letech, že v GRD v režimu ET je řada problémů. Ty jsem snad napravil
a ještě přidal režim ET:2, způsobující vynechání otázky na Zapsat/Storno.
*******************
23.06.2017
Učiněny dva doplňky

.disable/.enable round

vypnutí/zapnutí zaokrouhlování - implicitně .enable round

po chybě ošetřené .onerr ... je v textové proměnné $chb text chyby.
*******************
Možnost

n=$m

místo

n=num("m")

je vyřazena po příkazu .oldname.
*******************
Ještě na žádost JUMPu ošetřena chyba vzniklá chybnou zpětnou dešifrací prázdných
tabulek po zaplacení jisté sumy v bitcoinech firmě způsobující zašifrování dat.

Evidentně se jedná o chybu v algoritmu buď při šifrování nebo dešifrování. Normální
by bylo to reklamovat u firmy, které jste zplatili! a ne u Software-REDAP.
*******************
21.06.2017
Na předchozí poznámku žádná reakce, nicméně jsem to dotáhl na:

<* VST *>
$SN, $SD, $IN, $DE, $DO,$VP, $F4, $ESC, $F2, $NA, $CR,$F1,$TB
Pgu-vzad Pgd-vpř Ins-vst Del-maže |-opk F4-Co? Esc-konec F2-vše <-zpět
<* INF *>
$SD, $SN, $q, $ZA, $KO, $n, $t, $r, $F4, $ESC
Pgd-vpřed Pgu-vzad Q-běž Home-zač End-konec N-nepiš T-piš R-rel F4-Co Esc-opusť
<* DED *>
$SN, $SD, $VL, $VP,$CR,$NA,$DO, $AIN, $SF4, $Esc, $DE, $BS
pgu-vzad pgd-vpř <-zpět >-opk ^-nah |-dol altins-vst shiftF4-Co? Esc-opusť

Doplněno $<znak> - dekadický kód znaku. !!Rozlišujeme malá a velká písmena!!
******************
14.06.2017
Dnes jsem dumal, proč v init5w máme stále číselné kódy místo mnemotechnických zkratek.
Ukázalo se, že problém záměny kódu na zkratku v této části WR není triviální. Podařilo se
mně protlačit změnu:

<*329, 337, 338, 339, 336,333,318, 27, 316, 328, 13,315,9*>
$SN, $SD, $IN, $DE, $DO,$CR,$F4, $ESC, $F2, $NA, $CR,$F1,$TB
Pgu-vzad Pgd-vpř Ins-vst Del-maže |-opk F4-Co? Esc-konec F2-vše <-zpět

Zdá se mně to průhlednější a jak vám?
******************
25.05.2017
Uchozena v HTTP a HTTPS změna zadání portu:

.readhttps "isir.justice.cz:8443","isir_cuzk_ws/IsirWsCuzkService"#"insd.xml","inso.xml"

jak je zvykem přes dvojtečku za jménem serveru. Jinak tento příkaz nahrazuje:

cmd curl -k -H "Content-Type: text/xml; charset=utf-8" -H "SOAPAction:"
-d @insd.xml -X POST https://isir.justice.cz:8443",
"/isir_cuzk_ws/IsirWsCuzkService >inso.xml

Je to ve skutečnosti jeden řádek rozdělný zde do tří řádků.
******************
23.05.2017
Takže díky realizaci HTTPS + SOAP není třeba v EET CURL (OPENSSL jsme nahradili
již dávno). A pomocí SFTP můžete realizovat bezpečnou údržbu www stránek.

Stálo nás to +50 kB oproti WR585. Přitom CURL.EXE + SFTP.EXE dá 3.5 MB.
******************
21.05.2017
Nepodařilo se pouze najít interpretaci .cdsftp - tedy změnít implicitní
knihovnu. Z toho titulu .getdirsftp vrací vždy "/".
******************
20.05.2017
Zdá se, že v rámci SFTP funguje:

.opensftp "<IP>","<User>","<Password>",10
.dirsftp "<adresář>","dir.txt"
type dir.txt
.writesftp "c:\wr586\dok585.xhl","<adresář>/com.cpp"
.readsftp "<adresář>/com.cpp","com.bak"
dir com.bak
.closesftp

Výhodou by mělo být, že user+password jsou již zašifrovné a rovněž tak
přenášené soubory.

Snahou je a bude, to syntakticky udělat shodně s příkazy FTP.
******************
16.05.2017
Malý soubor úspěšně odeslán. Vedlo to na realizci příkazů:

.opensftp
.writesftp
.closesftp

Nyní ještě zvládnout odeslání velkého souboru a program trochu "učesat".
******************
13.05.2017
Dopracoval jsem se k příjmu 18. balíčku z celkové komunikace o 28 balíčcích.
Stále jsem ale nedokončil operaci .opensftp.
******************
11.05.2017
Genialita SSH2 mně jaksi uniká. Např. před zahájením šifrované komunikace mně
server pošle pouze svůj veřejný klíč (ne certifikát abych si mohl ověřit pravost
protějšku) a soukromým klíčem podepsaný hash dosavadní komunikace. Já to pracně
dešifruji (to může udělat kdokoliv - klíč a podepsaný hash je v jednom balíčku) a
porovnám to s mým hash a musí to klapnout. Kdyby ale server poslal pouze ten hash
(ne podpis hashe), nebylo by to tak vznešené, ale výsledek z hlediska utajení by byl
ten samý.
******************
10.05.2017
Zpracoval 4. zprávu serveru a vygeneroval 5. a 6. zprávu (poslední již šifrovaná)
a přijal zatím bez porozumění krátkou 5. zprávu od serveru. Takže jsem skoro na 11 z 28.
Přirozeně úvodní takty jsou nejobtížnější, protože se domlouvá komunikace a generují
se šifrovací klíče. Po zvládnutí šifrování a dešifrování a generování a kontroly
KS bloků, jde pak již jen o vlastní distribuci konkrétních příkazů.

Jinak je ten protokol SSH2 opět dílem šílených programátorů. Vlastní zdrojový program
pokračuje ve šlépějích kódu OPENSSL. Používají se superstruktury (struktury obsahující
opět struktury a ty opět struktury). Když si jednoduše zavolám překódování bloku, tak
zde se jede postupně voláním rutin a až řádově na desátém zanoření se provede překódování.

Kontrola komunikace je dosti obtížná, protože klíče jsou dílem náhodných čísel a každý
blok je doplněn řadou náhodných čísel, takže každé spuštění programu pracuje s jinými
hodnotami. Protože je to založeno na KS MAC, hash Sha1 a Sha256 je vše při každém spuštění
zcela jiné. Výpočty se zde drží na 192 bajtových číslech = 384 oktalových cifrách.

Stále platí, že likviduji obecnost zdrojového kódu (jako v OPENSSL a CURL) a když se
prokoušu stovkami řádků zdroje a pochopím o co jde, nahradím to několika řádky ve WR.
Takže v EET jsem studoval kód OPENSSL, v HTTPS kód CURL a nyní kód SFTP. Protože se
z CURL i SFTP volá OPENSSL, využívám dost podstatně zkušeností a rutin nabytých a
vytvořených v loňském roce.
******************
06.05.2017
Po poměrně úporné snaze jsem schopen v rámci .opensftp vygenerovat 4 zprávy
a dostat ze serveru 4 odpovědi. Tedy 8 zpráv z celkového počtu 28 představujících
komunikaci pro zaslání jednoho souboru na server.
******************
24.04.2017
Začal jsem se rýpat v SFTP - širované FTP. Během tří dnů se mně podařil sestavit
příklad na SFTP-WRITE a teď ho budu analyzovat a vytěžovat. Prográmek má 1,8 MB.

Doufám, ze si uvědomujete, že WR585 obsahuje openssl.exe a WR586 nyní i curl.exe,
takže v distribuci ubylo cca 3,5 MB a WR nakynul o cca 50 kB. Věřím ,že i SFTP
nám WR moc nenafoukne.
******************
22.04.2017
Z mého pohledu považuji .readhttps za ukončené. Teď budu očekávat eventuální popis
problémů při aplikaci .readhttps od vás.
******************
18.04.2017
Zabudoval jsem do stroje timeout, protože se to občas kouslo při žádosti o další
porci znaků. Jinak nevím, jak je stroj na serveru udělaný nebo v PC, protože
to dává dosti nahodile různé délky úseků informace. Člověk by očekával, že při stejném
dotazu, stejně dlouhém, dostanu stejnou sekvenci úseků informace. Opak je pravdou.

Při neúspěchu to opakuji až 5x. Nejčastější chybou je, že handshake (navázání spojení)
selhal. Až na málo pravděpodobné stavy, to stačí.
******************
17.04.2017
Poněkud zlepšena stabilita .readhttps. Nicméně po změně v TRZBA.cmd

.;'curl' 'https' --data @uctenka.xml -m 10> odp.xml
.readhttps "pg.eet.cz","eet/services/EETServiceSOAP/v3"#"uctenka.xml",odp.xml

občas FIKa nedostanu.
******************
16.04.2017
Vypadá to, že se blížím k cílovému stavu a to v eet vynechat podporu curl. V prvním
kole mně .readhttps vracelo "Neplatný podpis SOAP zprávy". Pak mně napadlo, že podpis
realizuji nad textem bez CRLF. Takže jsem je z UCTENKA.XML odstranil a ejhle, dostal
jsem FIKa! Takže curl zřejmě vypustí CRLF před přenosem též.
******************
15.04.2017
Zdá se, že se WR nafoukl díky .readhttps o 37 kB, což není nic významného.
********************
15.04.2017
Tak po čtyřměsíčním rýpání mám jakousi relativně syrovou .readhttps. Naučil jsem ji
GET, POST a SOAP a je tak plně kompatibilní s .readhttp - stačí přidat "s". Prošlo mně

.;GET
del odpoved.xml
.onerr #; .readhttps "wwwinfo.mfcr.cz","cgi-bin/ares/ares_es.cgi?ico=xxxxxxxx","odpoved.xml",5
.testfile odpoved.xml
.if($filerr==1) edi odpoved.xml

.;POST
.OPEN DOTAZ.TXT
.DATA ico=xxxxxxxx
.CLOSE
del odpoved.xml
.onerr #; .readhttps "wwwinfo.mfcr.cz","cgi-bin/ares/ares_es.cgi"!"dotaz.txt","odpoved.xml",5
.testfile odpoved.xml
.if($filerr==1) edi odpoved.xml

.;SOAP
del dphodp.xml
.onerr #; .readhttps "adisrws.mfcr.cz","adistc/axis2/services/rozhraniCRPDPH.rozhraniCRPDPHSOAP"#"dphdot.xml","dphodp.xml"
edi dphodp.xml

kde za xxxxxxxxx si dejte nějaké IČO, poslední je dotaz na nespolehlivého plátce.

Podporuji zatím pouze dva protokoly a uvidíme, zda to bude stačit. Neumím ověřit pravost
certifikátu serveru - je to jako curl s "-k". Jinak "s" nelze obecně přidat, protože
server musí umět dotaz zpracovat i v režimu https.

Jinak touto akcí reaguji na stále sílící trend přechodu na zabezpečený protokol https i když
v řadě případů to považuji za zbytečný přepych. Navíc třeba 2 bajty (CRLF) informace se
posílají jako 53 bajtů 5+(délka+16+20+15)/16*16.
********************
07.04.2017
Zdá se, že se zadařilo v režimu GET stáhnout obsah úvodních stránek pro

https://www.example.com - eliptická křivka
https://ec.europa.eu - DH protokol

a mírně zjednodušit a zefektivnit potřebný kód pro tyto operace.

Teď se budu pokoušet o metodu POST a SOAP. Přirozeně není jasné na jiných
servrech, co budou akcetptovat za protokoly. OPENSSL jich nabízí serveru cca 30,
já mám zatím dva.

DH je poměrně pochopitelný. Server poskytne veřejný klíč, já vygeneruji 46 bajtový
náhodný klíč, podepíši ho veřejným klíčem serveru a pošlu ho serveru a mělo by platit,
že se to dá dekódovat pouze pomocí soukromého klíče serveru. Na základě tohoto klíče
se pak vede dialog. Kódování a dekódování je proudové, tj. nutno dekódovat zprávu
za zprávou a podobně šifrovat zprávu za zprávou. Pokud by něco vypadlo, přestane
to fungovat - bude to buď na straně serveru nebo mojí rosypaný čaj. Každá zpráva
má kontrolní součet - poměrně složitě ověřitelný - jinak se vytváří KS odcházející
zprávy a jinak je vytvořen KS přicházející zprávy. Pracuje se s SHA1, SHA256 a SHA512.

U eliptických křivek se počítá s 64 cifernými oktalovými čísly, modulo jakési
prvočíslo stejného rozměru. Sebekriticky přiznávám, že jsem výpočet převzal
ze vzorového programu a moc jsem nepochopil, jak na základě zadaného bodu a typu
křivky serverem a mnou vygenerovaným náhodným číslem lze šifrovat a dešifrovat zprávy.
********************
27.03.2017
Můj předpoklad, že servery HTTPS jsou nadprůměrně inteligentní padl. Zdá se, že
každý umí jen určitou třídu protokolů. www.example.com a pg.eet.cz eliptické
křivky, ec.europa.eu DH (Whitfield Diffie and Martin Hellman) protokoly.
Takže můj předpoklad, že jako klientovi mně bude stačit umět jeden protokol, padl.

Po dalším testování se zadá, že první dva uvedené servery akceptují i DH protokol,
zatímco ec.europa.eu pouze DH protokoly. Akceptace DH se ale nepotvrdilo.
********************
26.03.2017
Podařilo se přečíst z www.example.com informaci. Moje štěstí netrvalo dlouho. Zkusil
jsem ec.europa.eu a odpoveď Allert. Postupně jsem zkonstatoval, že server neumí
Cur23 - s kódem 0xc013, ale nabízí šifrování 0x0039, které neumí testovací program a
tedy ani já.
********************
23.03.2017
Tak po několikaměsíčním snažení jsem zaslal ClientHello, obdržel ServerHello, zaslal
závěr dohadování serveru a server to pochopil a poslal též závěr dohadování
o způsobu spojení a šifrování. Což je přirozeně dílčí úspěch, ale cíl je ještě
daleko.
********************
21.03.2017
Konečně se podařilo ověřit hash přijatého bloku v https. Tak zatemněný kód v ověrovacím
kódu jsem snad nikdy nezažil. Z 350 řádků vzoru jsem vyrobil kód o 29 řádcích. Pokud blok
vyrábím a posílam, je konstrukce hash bloku odlišná od tvorby hash bloku serverem.
To je skutečně duševní rozcvička!

Takže umím poslat zašifrovaný blok serveru na základě úvodní komunikace a dešifrovat
a ověrit hash přijatého bloku. Zatím ale význam přijaté informace neřeším.
********************
17.03.2017
Přepracoval jsem formálně SHA1, SHA256 a SHA512 a bude povoleno

.crypt_hash "<vstup>","sha512","<hash64>"

Připomínám, že SHA1 dává hash 20 bajtů, SHA256 32 bajtů a SHA512 64 bajtů.

Do PIPu přidán přepínač /bi odpovídající /ap, s tím, že se předpokládá, že
spojované soubory jsou binární.
********************
10.03.2017
V kauze https mírný pokrok. Pro širování a dešifrování je nutno vygenerovat dvě
a dvě různé sady klíčů, jeden klíč je měněn v průběhu šifrování/dešifrování. Nelze
tedy například při dešifrování vzít nějakou zprávu, ale je nutno dešifrovat
zprávy v pořadí, jak přicházejí, jinak získáte humus.
********************
07.03.2017
Zdá se, že se zadařilo vyrobit prvních 235 bajtů jako částečně zašifrované informace
na zprávu od serveru. Takže umím tři takty - ClientHello analyzovat ServerHello, vypočítat
na základě náhodného čísla bod ekliptické křivky ze zprávy serveru, najít afinní
souřadnice bodu, odvodit z toho master key. Vygenerovat pro AES šifru klíče a
umím udělat kontrolní součet jednotlivé zprávy a zašifrovat ji AES šifrou. To vše
promítnout do zmíněné zprávy o 235 bajtech obsahující dvě otevřené zprávy a dvě
zaširované zprávy.

Zbývá tedy se naučit dešifrovat zakódované zprávy ze serveru.
********************
06.03.2017
Zadařilo se vyvořit init+encryp AES_128_cbc a blok informace obalit vpředu
16 náhodnými bajty, vzadu 20 bajty s MAC podpisem a doplnění do násobku 16
vhodnou výplní a pak zašifrovat AES_128_cbc. Tím je informace připravena
k odeslání serveru. Nicméně cíl je stále ještě daleko.
********************
02.03.2017
Dnes se zadařilo v kauze https zašifrovat "master secret". Nejhorší na té
práci je, že v curl+ssl musíte projít mnohaúrovňové zanoření s desítkami struktur
mnohonásobně opakované, až pochopíte jádro pudla a celodenní bádání vede pro konkrétní
případ na 6 řádků mého programu. Dá se říci, že ta komunikace je dílo šílených
programátorů (to ji ještě celou neumím!) kvůli jiné skupině šílených programátorů,
kteří se snaží komunikaci dešifrovat a sledovat.
********************
23.02.2017
Do čárových kódů typu 128 přidán kontrolní znak. Komu se to nelíbí, může začít ~4
tj. nepřidávej kontrolní znak. Jinak jsem konstatoval, že programy na snímání
čárových kódů bez kontrolního znaku u typu 128 jakoby nefungují.
********************
22.02.2017
Jako obvykle je ve wr586d.zip časově omezené demo do 30.6.2017 v síťové verzi.
********************
22.02.2017
Pokud se tisknul prázdný obrázek, kompletně se tisk ignoroval - došlo k narušení
zobrazení. Nyní se vynechá pouze vlastní zobrazení bitové mapy.
********************
19.02.2017
V instrukci CSV byla změněna filosofie u přepínače RE. Dosud se vše převedlo jako RE.
Nyní, pokud sloupec není typově homegenní, deklaruje se jako RE, jinak DD nebo ND.
********************
14.01.2017
Pokud je v init5w. zadán přelomový rok menší než 30, opraví se na 30.