Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - mhi

Stran: [1] 2 3 ... 17
1
Hardware / Re:NVIDIA Jetson Nano
« kdy: Dnes v 08:19:14 »
Jako nevim co s tim chces jako delat za psi kusy, ale samotny OS pro tuto desku absolutne nema smysl davat na cokoliv rychlejsiho nez ty 90MB/s SD karty, je s tim vice prace, nez praktickeho uzitku. Radeji bych to pouzival tak, ze OS bude na SD a data na tom suplicku.

Za mne pridani rotacniho HDD k ARM desticce vyznamne zvysilo jeji pouzitelnost, uz jenom diky vytvoreni swapu. Takze za mne urcite ANO, chova se to pak daleko vic jako normalni pocitac. Jako zdroj jsem pouzil primo napajec v monitoru, disk integroval dovnitr za LCD, ARM desku pridelal na distancni sloupecky zezadu na monitor. Pouzival jsem to radsi nez stolni pocitac, bohuzel po cca roce mi ARM umrel, prisel COVID, homeoffice, ...

2
Vývoj / Re:Extrakce informací z PDF faktur
« kdy: 13. 01. 2021, 12:11:00 »
O neco takoveho jsem se pokousel v mini verzi pro interni pouziti, tak par rad od amatera.

0) EDI neni jen EDIFACT ( https://www.edi-plus.com/resources/message-formats/edifact/ ), byt tyto messages se snad jako jedine pro EDI skutecne v realnem svete pouzivaji. Mame tu UBL a z nej odvozeny cesky ISDOC. Neznam nikoho kdo by to poradne pouzival (protoze to bylo jednoduche, prikladame ISDOC do nasich PDF primo jako attachment v tom PDFku, takze se da rozkliknout).  Od dodavatelu jsem videl ISDOC snad jen u subreg.cz ...

1) z obecnych faktur spolehlive vytahnout nic nejde a ucetnictvi bych na tom nezakladal; takovou informaci lze myslim pouzit jen pro overeni zadanych udaju, nebo jejich predvyplneni.

2) PDF se prevede na text, aby to odpovidalo rozlozeni na strance, tzn. resi se radkovani (sesortuji se vsechny texty pres obe osy). Algoritmus ktery jsem zkousel je primitivni - v PDF lze identifikovat obvykle ceske IC, jakekoliv DIC/VAT#, ruzna data (vyst, duzp,...  ) a ruzne castky. Z castek lze u jednoduchych faktur urcit ktera je total, kde je danovy zaklad a dan.

3) Existuje jeste QR faktura a QR platba, malokdo to pouziva, obcas se objevi - jenze v PDF je implementovana obcas jako skalovany obrazek, obcas jako sada postscript prikazu, to se myslim ani nevyplati resit.

4) data z bodu 2) jde ale efektivne pouzit k vyznaceni rucne zadanych hodnot, ktere program najde v PDF, to je primitivni vec a urychli to kontrolu zadanych udaju.


PS: Muj znamy dela http://www.qinve.com/en/

3
Windows a jiné systémy / Re:Windows CE 6.0 a jeho oprava
« kdy: 04. 01. 2021, 20:07:07 »
Dobry zacatek by byl rozjet ten J-Link s danou deskou a dokazat zastavit ten ARM core a vydumpovat si treba kus pameti (adresu vezmete treba z aktualniho r15/pc). Az to budet mit, napiste.

4
Windows a jiné systémy / Re:Windows CE 6.0 a jeho oprava
« kdy: 01. 01. 2021, 22:52:30 »
Sel bych cestou serioveho portu, protoze pres JTAG to vidim dost beznadejne, pokud nenajdete nejaky vhodny nastroj ktery umi prave tu Vasi desku. Mate pred sebou celou radu ukolu, jednak zjistit co presne to je za SoC, jake ma periferie. Pak je potreba prijit na mapovani NANDu (oboji pujde nejspis snadno z datasheetu), a nakonec musite zjistit jak je ten NAND reseny, jakym algoritmem jsou mapovana data na sektory. A protoze se ptate "jak na to", je videt, ze kazdy z tech ukolu bude celkem tezko prekrocitelny. Pritom to vsechno by mohl vyresit nejaky bootloader uvnitr za Vas.

Jinak na ebayi se da koupit J-Link (samozrejme je to plagiat), ktery funguje se Seggerackymi nastroji, ktere by mohly byt nejdale tomu co potrebujete.

5
Windows a jiné systémy / Re:Windows 10 ARM na Raspberry PI
« kdy: 01. 01. 2021, 19:33:16 »
Pro ty co zajima problematika binar translatoru (JITu) x86->aarch64 je pekny clanek: https://blogs.blackberry.com/en/2019/09/teardown-windows-10-on-arm-x86-emulation

Mam nejake dumpy sveho x86 procesu z pameti z WoA, zatim nechapu spoustu veci, ale nejak to chodi (byt na RPi3 to je naprosto nepouzitelne, aplikace ktera trochu flickeruje na intelu na tom ARMu jede tak, ze vidim jak se kresli jednotlive casti okna :-) ). Musim prijit na to jak pomoci nejakeho debugapi vytahnout info o cpu contextu daneho threadu, aby se dalo zrekonstruovat co to vlastne dela.

6
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 01. 01. 2021, 12:39:58 »
Je rozdil mezi 'zdrojakem vs libc' a 'executable vs libc'. Privedl jste mne ale na jednu myslenku, co povazuju za mor dnesniho IT sveta, a to je jak moc na pocatku chybi nejaka vize (+zkusenosti) toho co ma urcita knihovna umet, jak ma byt strukturovana, schopnost navrhnout dobre nejake API apod. Dneska se kod spis lepi a pak to vypada tak, ze prave glibc je neuveritelny moloch. To same msvcrt, apod. Je potrebna nejaka zmena? Udelame dalsi fci, pridame dalsi parametr, apod., zvedneme cislo v nazvu .so. a je hotovo. V horsim pripade se jen zmeni API a na zbytek se kasle. A to pak vede k tomu, ze se musi delat narovnavaky na ohybaky.

Moc casu tomu nemuzu venovat, ale uz jsem par malinkatych veci prelozil - pomoci opravdu nanolibc napatlane primo na ucel techto miniaplikaci a fascinuje mne jak ty .exe muzou byt male, svet je opet v poradku :-). Muj linker+nanolibc - 4kB. MSVC 2003 60kB; MSVC z 2019 - 180kB.

7
Vývoj / Re:Nalezení a zkopírování celého řádku
« kdy: 30. 12. 2020, 18:24:50 »
s/^(.*slovo.*)$/$1\n$1/g

 - neco na tento zpusob? Nutno upravit syntaxi pro konkretni regexp.

8
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 30. 12. 2020, 12:19:16 »
ad wsl: duvodu je vice, jednak potrebuju aby to chodilo kde WSL neni (predstavte si, ze je 3rd party SW ktery nechodi na W10), za druhe nechci 'sebou' tahat hromadu blbosti a resit ruzne kompatibility apod.

ad tcc: nevim o tom, ze by mela vlastni libc, pouziva nejakou systemovou, nebo se pletu? Ale to neni reseni, predstavte si, ze mate 20 projektu, ktere v sobe obsahuji nejake zavislosti na konkretnim prekladaci (typicky treba nejaky inlinovany assembler AT&T stylu ... nebo naopak ten MS-to je dalsi vec nad ramec tohoto tematu kterou chci nekdy vyresit, abych msvc COFF/objectfile mohl pouzit v Linuxu). Najednou se stane jednodussi vyresit nejake 'hloupe' libc nez  koukat jak zmena prekladace vyvola nekonecny seznam chyb, ktere clovek musi tupe opravovat.

No ale zajimaly by mne tipy na ruzne male libc, muj favorit je openbsd, inspirovat se chci ale i u prekladacu z Win sveta (msvc, bcc), dale uclibc, musl libc, dobrym zdrojem jsou nejake opravdu historicke libc typu https://github.com/wuzhouhui/c_standard_lib ; naopak treba Watcom je plny DOS/OS2/Win3x legacy kodu

9
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 29. 12. 2020, 19:46:08 »
Podle me qemu-user neresi ABI, ale mozna se pletu.A jestli to bylo mysleno tak ze si mam to ABI do toho nejak zadratovat sam, tak to je jednodussi udelat tu libc.

Narazil jsem ale na zajimavy problem a to je TLS, gcc v Linuxu totiz na takove promenne pristupuje jak se mu zachce via gs:xxx (R_386_TLS_LE) , ve Windows to je ale potreba pres TlsIndex a pak fs:[0x2C]. x86_64-w64-mingw32-gcc na to ma zadratovany hack a pomaha si pres ___emutls_get_address. MSVC to prelozi ze si rovnou vytahne z fs:[0x2c] co potrebuje a pres globalni tlsindex leze kam potrebuje. Jak toto vyresim nevim.

10
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 29. 12. 2020, 17:50:19 »
Diky za tip, povedlo se vam to nekomu stahnout? Nejak se nemuzu dopidit jak se dostat k privatnimu githubu se zdrojaky (mam access denied).

Kazdopadne mi to prijde jako tezky overkill, oni tam resi sice podobny problem, ale knihovna se patla treba v prekladu unicode na utf8, pochybuju navic ze takovou vec prelozim nejakym starym gcc. Ja chci naopak minimalismus.

Uvazuju o 4 vecech:
- asi by bylo dobre pomoci inline fci nejak wrapnout unicode/ansi verze (misto #define CreateFile CreateFileA), aby to nezborilo pres define stejne se jmenujici fce v programu, netusite MS pouziva #define misto always_inline fce ?

- muzu pouzit spoustu fci z ntdll.dll, skoda ze nejde pouzit jejich fce xxxprintf, ledaze bych na to pouzil nejaky intermediate string buffer a pak tisknul pres nejaky snprintf, ale to se mi moc nelibi

- A pak bych rad vyresil chytre ty inline wrappery nad Win32 API jako je exit(n), stejne tak v mych programech neni problem udelat ze (file) HANDLE je to same co file deskriptor a ve wrapperu open()->CreateFileA jen poresit STDIN/OUT/ERR aby to zavolalo GetStdHandle(); dalsi problem je errno, nevim jestli si muzu dovolit udelat #define   ENOENT ERROR_FILE_NOT_FOUND (tady to zrovna sedi, oboji jsou 2, ale urcite se to jinde rozpadne).

- pokud by doslo k tomu, ze cast projektu bude prelozena s tim ze HANDLE == filedescriptor (tzn. ty inline fce) a cast ocekavajici translaci pres knihovni fce, mate nekdo tip jak zamezit vzajemnemu slinkovani takovych vzajemne nekompatibilnich obj files ?

11
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 29. 12. 2020, 15:57:14 »
Mingw je myslim tvrde zadratovane proti msvcrt, to nechci, nebude to chodit.

Tak jsem se do toho pustil. Slinkuju helloworld :). Nejvetsi problem byl tedy poslepovat z jinych projektu konvertor ELF to EXE/PE, aby to umelo spravne prehazet ELF z noveho gcc, generuji se tam nektere veci trochu jinak nez jsem byl zvykly. Navic mi IDA hazi ze import tabulku mam poskozenou, tezko rict co tam mam blbe - EXE ale normalne chodi.

Vysledek:

Kód: [Vybrat]
#include "../windefs.h"

#define STD_INPUT_HANDLE    ((DWORD)-10)
#define STD_OUTPUT_HANDLE   ((DWORD)-11)
#define STD_ERROR_HANDLE    ((DWORD)-12)

WINBASEAPI
HANDLE
WINAPI
GetStdHandle(
    _In_ DWORD nStdHandle
    );



WINBASEAPI
BOOL
WINAPI
WriteFile(
    _In_ HANDLE hFile,
    LPCVOID lpBuffer,
    _In_ DWORD nNumberOfBytesToWrite,
    _Out_opt_ LPDWORD lpNumberOfBytesWritten,
    _Inout_opt_ void *
    );

WINBASEAPI
DECLSPEC_NORETURN
VOID
WINAPI
ExitProcess(
    _In_ UINT uExitCode
    );

typedef int ssize_t;
typedef int size_t;
[b]
static inline ssize_t write(int fd, const void *buf, size_t count) __attribute__((always_inline));

static inline void exit(int status) __attribute__((always_inline));[/b]

int main()
{
    const char *hellostr = "Hello world\n";

   write( GetStdHandle(STD_OUTPUT_HANDLE), hellostr, lstrlenA(hellostr));

   exit(0);
}


void exit(int status) {ExitProcess(status);}


ssize_t write(int fd, const void *buf, size_t count)
{
  DWORD bw;
  WriteFile(fd, buf, count, &bw, NULL);
  return bw;
}

V disassembleru z toho vypadne:

Kód: [Vybrat]
.text:00401000 _text           segment para public 'CODE' use32
.text:00401000                 assume cs:_text
.text:00401000                 ;org 401000h
.text:00401000                 assume es:nothing, ss:nothing, ds:_text, fs:nothing, gs:nothing
.text:00401000                 public start
.text:00401000 start           dd 0FB1E0FF3h           ; toto je endbr32 :)
.text:00401004 ; ---------------------------------------------------------------------------
.text:00401004                 lea     ecx, [esp+4]
.text:00401008                 and     esp, 0FFFFFFF0h
.text:0040100B                 push    dword ptr [ecx-4]
.text:0040100E                 push    ebp
.text:0040100F                 mov     ebp, esp
.text:00401011                 push    ebx
.text:00401012                 push    ecx
.text:00401013                 sub     esp, 1Ch
.text:00401016                 push    offset aHelloWorld ; "Hello world\n"
.text:0040101B                 call    lstrlenA
.text:00401020                 mov     dword ptr [esp], 0FFFFFFF5h
.text:00401027                 mov     ebx, eax
.text:00401029                 call    GetStdHandle
.text:0040102E                 lea     edx, [ebp-0Ch]
.text:00401031                 push    0
.text:00401033                 push    edx
.text:00401034                 push    ebx
.text:00401035                 push    offset aHelloWorld ; "Hello world\n"
.text:0040103A                 push    eax
.text:0040103B                 call    WriteFile
.text:00401040                 push    0
.text:00401042                 call    ExitProcess
.text:00401047 ; ---------------------------------------------------------------------------
.text:00401047                 lea     esp, [ebp-8]
.text:0040104A                 xor     eax, eax
.text:0040104C                 pop     ecx
.text:0040104D                 pop     ebx
.text:0040104E                 pop     ebp
.text:0040104F                 lea     esp, [ecx-4]
.text:00401052                 retn


Pres ty inline pujde vyresit spousta veci relativne efektivne, napr. KERNEL32.dll:lstrlenA() budu aliasovat na strlen stejne jako to delam u exitu -> KERNEL32:ExitProcess().  Takhle asi udelam 2 verze knihovny, jedna ktera se bude snazit o maximalni kompatibilitu (tam nebude zadny inline-pro pouziti s dalsimi knihovnami/bloby/atd. ktere budou ocekavat existenci vsech symbolu) a druha ktera nageneruje z prvni knihovny ty inlines (a tim se to rovnou bude preklapet na Windows API).

Tusite jak primet gcc k tomu aby negeneroval ten bordel s endbr/stackem/frameptr ? Moje cmdline + verze:
gcc -m32 -c hello.c -Os -fno-PIC -fno-stack-protector -fomit-frame-pointer   # gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)


Pro rypaly: ten kod je proof of concept!

12
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 20. 12. 2020, 15:16:58 »
Vynechal jsem tu spoustu detailu. Muj kod je obcas michan s ruznymi historickymi knihovnami nebo jednotlivymi .c soubory, ktere jsem neprogramoval a nemam zajem travit svuj cas opravou neceho co vznikalo treba v 90. letech (a obsahuje to teba kod ve stylu K&R :) ). Dale tam jsou obcas casti v assembleru, nebo prilinkovany nejaky object. Mam to tak, ze urcite veci jdou prekladat jen urcitymi verzemi gcc, nebo "jen" nefunguji. Nechtejte po mne detaily, psal bych tu romany, jsou to vsechno interni veci, ktere se zatim nevyplati lepe udrzovat, protoze jich je moc a pouzivaji se malo casto.

Ten mingw je nejblizsi tomu co potrebuju, nicmene musel bych mit verze pro ruzne gcc, no mozna to jde poskladat, preci jen mi prislo jednodussi pouzit to co je overene ze chodi a jen to na stejnem stroji prelozit znovu s jinymi headerfiles a pak prekovertovat. Vyzkousim cestu prelozit si nejakou minimalistickou crt z bcc/watcom/msvc/...

13
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 19. 12. 2020, 12:54:57 »
Ja Vam rozumim, ale dabel je v detailech. Teda kdyby to byl jeden dabel, ale ono to je tisic malych dabliku a uz mne to nebavi opravovat a neustale resit nejake kompatibility. Popravde receno mi bohate uz staci jen zmeny ktere jsou v gcc, treba nedavno jsem stravil asi hodinu opravou cizich zdrojaku, cast diky 'double quote' C++ operatoru, ktery se mi nepodarilo vypnout ani zmenou normy C++ (navic kod byl celkem cisty C, jen to bylo hejno ".cpp" souboru).

Nekdy mrknu do nejakych starsich prekladacu typu Borland nebo Watcom na zdrojaky CRT, treba to pujde pouzit, myslel jsem ze existuje nejake free+opensource reseni.

Je to trochu offtopic, ale jsem donekonecna fascinovan tim jak mohou byt nektere veci slozite, treba kdyz se clovek mrkne do zdrojaku openbsd ci netbsd a srovna to s vecmi z OS/X, nebo Linuxu ... nebo srovna posledne zminovane s Windows :-). Asi uz starnu.

14
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 18. 12. 2020, 23:26:19 »
Bohužel tady asi neporadím. Jestli to chápu správně, tak se chcete vyhnout tomu, že byste vzal všechny ty malé zdrojáčky a pokusil se je kompilovat nějak nativně ve Windows, protože se bojíte, že by bylo třeba příliš mnoha změn v tom, co zatím funguje.

ano, chapete to spravne. Krome  toho je jeste duvod ze kdyz udelam nejake zmeny nechci nasledne byt nucen to dodatecne nekde jeste kompilovat, abych pak zjistil, ze jsem zapomnel ... a mam ruzne verze na Win i Unixu.

s temi filedescriptory je jeste jedna potiz, treba dup2 :). Ale takoveto veci nepouzivam. Mozna je reseni nakonec obslehnout msvcrt.

15
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 18. 12. 2020, 22:41:16 »
Dekuji vsem za tipy "jak to resit jinak". Vetsinu jsem myslim zvazil a nejsou uplne vyhovujici.

Jedna se o celou radu malych 'projektu', ktere kompiluju historicky na ruznych strojich, dokonce s ruznymi Unixy (primarne to je Linux). Vsude je ale GCC do ELFu. Prikladem takoveho projektiku je disassembler pro nejakou lehce neobvyklou ISA. Bez toho abych musel resit nejake kopirovani zdrojaku, jejich modifikaci pro kompilaci v MSVC/watcom/borland/whatever, bych rad nabuildoval Win32 verzi.

Skutecne bych potreboval jen zdrojak nejake minimalisticke posix/libc navazane na Win32 API. Tedy aby open vypadal nejak tak, ze prehaze parametry a zavola CreateFileA (/W). A pak zkontroluje navratovou hodnotu a opet nastavi spravne errno.

Mozna si nabiham na vidle, protoze to treba neni tak uplne jednoduche, uz jen kvuli tomu ze ve Win myslim neni jasne definovany stdin/out/err ( ... GetStdHandle(STD_xxx_HANDLE)) takze asi i takovato blbost jako preklad tech handles se musi resit.

Koukal jsem do zdrojaku VC++ crt a MS resi mapovani skrze '#define _osfhnd(i)  ( _pioinfo(i)->osfhnd )' ... coz prinasi celou radu problemu s lockovanim...achjo.

Stran: [1] 2 3 ... 17