Sigil: Diskusní fórum

Takže jde v Javě zavolat fce z Win32 API (C)? Třebas i ve stylu hoď eax na zásobník, najdi adresu fce v paměti, vyzvedni výsledek ze zásobníku.

Ono C nabízí nejvíce možností, jak ovládnout systém - vše ostatní je schované za různé front-endy ap. (a to včetně MFC, .NETu i Javy). On za to ale nemůže jazyk C. Spíše jde o to, že všechno, co systém umí, umí skrz funkce C a ostatní -endy se na to akorát nabalují. Až někdo udělá primární rozhraní systému v Javě (.NETu), bude to konec jedné legendy. Zatím se docela bavím při pročítání .NET fór, kde se pořád někdo ptá, jak udělat to a to a odpovědí jim je ať použijí tuhle Win32 API funkci .

Ten druhý odstavec jsem trochu nepochopil, možná proto ž neznám Corbu. Ale OS a aplikace musí mít jinou pozici už z důvodu bezpečnosti. Nikdo z nás se myslím nechce vrátit k reálnému módu. Moje aplikace si nicméně může i dnes dělat víceméně co se jí zlíbí. Já jsem si shodil kompletně XP svým programem a to jsem to ani nechtěl.

Konkrétně k mému programu: Pominu-li svoji averzi k interpretovaným jazykům, tak mi ale nepřijde nijak výhodné psát tu utilitku v něčem jiném než C. Toho GUI tam moc není, přenositelnost je k ničemu (BG stejně nepoběží na Macu) a program se vlastně celý skládá z volání nestandardních API funkcí (nízkoúrovňové hookování přerušení vstupu, zablokování překreslování oken, injectnuté události myši).

drake127: V Javě jde volat tzv. "nativní" fce napsané v jiných programovacích jazycích (nejen C/C++). V C/C++ napíšeš fci s příslušnou signaturou a dle JNI specifikace, která v sobě obalí všechna nutná volání třeba Win32 API, a pak tuto fci z Javy zavoláš.

Tady nejde o přenositelnost, ta je v tomto případě stejně rázem značně narušena, ale třeba o ta vlákna a další aplikační záležitosti, které Java zvládá přímočařeji nežli třeba C/C++. Právě proto mé oko spočinulo na tvém postu kolem vláken a unicodu relevantních rozdílu mezi starými a novými win.

S dalšími odstavci v podstatě souhlas - jisté výhody C/C++ jsou nesporné a ta aplikace je charakteru, kdy je to zřejmě skutečně výhodnější napsat v céčkovém jazyku. Je třeba ne zcela - a to je právě ta otázka. Svět je dnes neskutečně široký (sw, hw, byznys, svět vůbec) a obsáhnout ho jedním suknem mi přijde takřka nerealizovatelné (a tady mi přijde, že o to se právě snaží MS), proto je alfou a omegou zejména kooperace a integrace různých systémů a platforem a to hlavně stylem nějakým otevřeným ve smyslu nějakých konvencí, standardů a projektů.

K interpretovaným jazykům - no, to je věc vkusu Mně se naopak líbí velmi Velmi zajímavou věcí je třeba Smalltalk (už jen proto, že má mnoho implementací, už jen proto, že to je jazyk, prostředí, ide a do jisté míry až téměř OS... fakt, že za běhu programu jde editovat kód, jehož změna se interaktivně promítá do spuštěného programu, to říká mnohé ), ryze objektový jazyk - u toho by člověk čekal jisté výkonnostní problémy, jenže naopak - v některých aplikacích (a to i třeba vědeckých - AI, rozhodovací problémy,...) bourají implementace smalltalku své kolegy.

Vše je o tom, pro jaký účel daná věc je, a jak jsou využité její přednosti - dojít se totiž může k nečekaným výsledkům. Jednou z nejvýkonnějších objektových databází je GemStone dělaný právě ve Smalltalku...

...na vyšší úrovni obecnosti je už fakt, že samotné objektové databáze jsou mnohem výkonější než ty relační...

...a na další už třeba to, že klasická von Neumannova architektura počítače (a hlavně tedy paměti) používaná dodnes, je neefektivní pro mnoho, ne-li většinu dnešních aplikací, v porovnání s jinými možnými architekturami.


Každopádně, abych se vrátil úplně zpět, k Erynie, to "skenování" hodnot - zavání to sice spíš už crackováním - nemohlo by celou věc usnadnit (je-li to vůbec třeba) dumpování paměti?

Jinak pozn, BG hry pro Mac jsou

Odzadu: Nj vlastně na to jsem úplně zapomněl ... hehe ... škoda, že o Macích jinak vůbec nic nevím. I na fakultě o nich není ani vidu ani slechu.

Dumpování paměti mě napadlo a snad by i šlo provést, ale jak zjistím, kde se ty hodnoty v paměti nacházejí. IMHO jsou to automatické proměnné, takže budou někde na zásobníku (:arrow: pokaždé jinde). Do určité míry by to aplikaci zjednodušilo (i když pro zkoušku je lepší tahle verze, protože ukazuje z vnitřností Win32 víc). Jediný způsob, co mě napadl, je dát uživateli opsat několik hodů a pak je navzájem porovnat. Bojím se ale, že tak malých čísel tam bude mnoho a bylo by to časově i paměťově náročné. Ovšem následně by to asi bylo méně problematické.

Já souhlasím, že ne ve všech oblastech je interpretovaný jazyk katastrofa a u některých výpočtů je možné dosáhnout srovnatelných rychlostí i s nativními aplikacemi, ale jedná se o speciální případy a dělají to lidi s citem pro platformu. Pokud v Javě napíšu smyčku for(;;);, tak věřím, že poběží podobně rychle jako v C++. Ale pokud začnu s GUI, I/O a rekurzivním volání několika na sobě navázaných funkcí, už bych o té rychlosti nebyl tak přesvědčený (byť jsem to prakticky netestoval).

No jo, tak tady ~C jazyky těží ze své novosti. Holt v dobách vzniku 32-bitových Windows nebo snad dokonce C++ byly vlákna v plenkách, stejně tak neexistoval unicode a vlastně začínaly locales. No a všechny ty meziverze se na C (i ve smyslu knihoven) nabalovaly jak přicházely. Takže dnes programátor musí brát v úvahu, jaké fce byly dostupné na kterém systému a podle toho to buď ošetřit nebo vyžadovat určitou verzi Windows (jádra, knihoven, kompilátoru). V Javě je to IMHO podobné, jen to člověk neuvidí na těch dnes už normálních věcech jako je unicode nebo vlákna - počítalo se s nimi už při návrhu a ty rozdíly v implementaci bylo možné ukrýt.

drake127: no, macy jsou u nás vůbec dost opomíjené - a to hodně velkým neprávem, i když - blýská se pomalu na lepší časy.

ad dumpování - možná by tam šlo najít nějaký pattern, dle kterého by se pa offsetově či pomocí heuristik (třeba "nasnímkování" prvních několika hodnot a jejich dohledání - tj. zautomatizování toho psaní hodů).

ad výkonnost - ono to takhle od stolu nejde říct, co zrovna rychlé je a není. Prázdný cykl je dost nedemonstrativní test . Tady je dobré pamatovat na to, že interpretované jazyky mají hodně pokročilých technik, co se týká interpretace. Kupříkladu Just In Time (JIT), která frekventované pasáže kódu kompiluje za běhu do nativního kódu (samo, že to stále nestačí na ručně vytuněný céčkový kód plný triků - ale to už je spíš otázka toho, jak kdo umí trikovat - v defaultu je to o tom, že frekventované výpočty jsou prostě nativní stejně jako přeložená céčková aplikace). Za běhu lze pak taky provádět další optimalizace, které staticky provést nelze.

Co se týče vláken a novinek - to je pravda, nicméně to je právě výhoda virtuálního stroje a objektového charakteru jazyka. Kupříkladu vlákna nejsou v Javě vůbec systémová věc - je to záležitost VM, a tak je s nimi v základech stejně nakládáno od Windows po mobilní telefon.
Podobně pak další myšlené i nemyšlené featury (ovládání programu řečí, okem, aplikační paralelní agent, xyz) - programátora zajímají veřejná API, tj. to, co "vidí". Co je vevnitř, to ho až tak zajímat nemusí. Zvlášť v architektuře s virtuálním počítačem, která odstiňuje i hw.
Takže člověku stačí vědět, že je nějaké (kupříkladu ) Java Speech API a že je to doplněk do grafu objektové hierarchie, že to produkuje Eventy polymorfní s EventObject atd. atd. Takže zapojení novinek je celkem transparentní - systémovější věci řeší VM, sw záležitosti pak objektová koncepce jazyka.

V jazycích s virtuálním počítačem zkrátka existuje mezivrstva, která umožňuje jisté mapování/simulaci mezi tím, co umí a jak dělá ten který OS, a tím, co člověk požaduje v programu; za cenu dodatečného výkonu na tu mezivrstvu samozřejmě... - ale některé metody zajišťují takřka "eliminaci" dodatečné režie interpretace, či přinášejí nové možnosti v optimalizaci. Takže ono to až dramatické není - někde ne, někde ano.

Vlasák píše:drake127: no, macy jsou u nás vůbec dost opomíjené - a to hodně velkým neprávem, i když - blýská se pomalu na lepší časy.

No, jestli myslíš blýskáním na lepší časy to, že Apple konečně začíná používat hardware od Intelu a software od Microsoftu, tak nemůžu než souhlasit

7c: myslím tím spíš to, že se macové technologie začínají prosazovat i u nás. Nedávno otevřená značková prodejna, ipody a tak

S tím MS softtem by mě docela zajímalo, v jaké to tam je formě - jestli porty z nouze, anebo plnohodnotné aplikace pro mac. Každopádně myslím, že na své osvědčené portfolio si sáhnout nenechají a jde jen o krok, kterak se otevřít světu ms-uživatelů...

Vlasák: Tím "software" mám samozřejmě na mysli operační systém Konkrétně Windows XP

7c: tak to už ani nejde považovat za macy

Tak ale C++ má také knihovny něčeho, vždyť to ani nemusí být objekt. Přece není problém napsat
if (LoadLibrary("Win07Look.dll")) SetSuperLook();
a máš v aplikaci podporu vzhledu ještě nevydaných Windows i se zpětnou kompatibilitou.
Toto je ve Win32 API pěkně vymyšlená metoda. Funkce definuje strukturu, kterou jí předáš jako parametr a její první položka je její velikost v bytech. V novějších verzích se do ní můžou přidat položky a fce pozná s jakou verzí má tu čest (protože se položky řadí v paměti popořadě, je velikost struktury vždy první).

Ono v Javě budou problémy podobné, jen je její výhoda v tom, že se dá aktualizovat Virtual Machine nezávisle na systému. Funkce systému se můžou aktualizovat jen s novějším systémem (popř. standardními knihovnami jazyka). Pokud bys ale musel počítat, že na 30 % stanic běží JRE 1.4 místo 1.5, byl bys tam, kde jsem já s Win32 API.

Ale samozřejmě s tebou souhlasím, že každé má svoje pro a proti. No a já si vybral C už jen kvůli tomu, jaké šílenosti v něm jdou udělat a jak blízko jsi ve skutečnosti k různým vychytávkám. Nedávno můj spolubydlící odlaďoval svůj program na počítání něčeho (fyzik) a měl ho napsaný v C, přičemž sledoval v externím programu jak efektivně je využívaná cache procesoru a opravoval podle toho program. To prostě v žádném vysokém jazyku nemáš možnost efektivně ovlivnit.
*((int *)(0)) = 5;

drake127: jo, to je dobrá funkce, nicméně nezaručuje žádný polymorfismus. Explicitně se testuje, jaká verze je. Pakliže je těch testů v aplikaci pár, nevadí to (nemluvím tu z hlediska výkonnosti, ale návrhu), pakliže víc, neřkuli o switchích atp., pak už vzniká moloch. S hierarchií interfaců a tříd je mnoho ifů a switchů eliminováno. Bez nějakého if o instanceof něco.class se člověk sice ne vždy obejde, ale většina logiky kolem kompatibility se vtěsná do okamžiku vytvoření konkrétní instance. Je-li to dobře navržené, pak se už nemusím starat a volám svoje notoricky známé metody.
Ano, takto lze navrhnout (otázka, zda i ve složitější situaci) i nějaký systém knihoven, ale pak je to jen objektové myšlení postavené tak trochu na vodě a nějakým ze známých nešvarů (opakující se kód, explicitní udržování závislostí, ad hocovost,...) jistě bude trpět.

Jsme-li u JRE, on je možná úspěch, pokud dnes 30% uživatelů javy má JRE 1.4 Konvergence k novým verzím je v "ostrém nasazení" poměrně pomalá, což vede k častým úsměvným komentářům na adresu Sunu "Jó, ta sedmička, která vyjde za rok a něco a pořádně se bude používat za sedm, osm let..." Nutno tady dodat, že pc desktopové programy pro "domácí" uživatele nejsou majoritní koncovou skupinou. Věcí ale je, že se situace zlepšuje a ten přechod už bývá rychlejší... takže tu 1.4 už má dnes snad většina, kolik ale pětku, to nevím, možná těch 30%... Což je trochu problém, protože sice existuje zpětná kompatibilita API, ale už ne tak zkompilovaných souborů.

Vlasák píše:Což je trochu problém, protože sice existuje zpětná kompatibilita API, ale už ne tak zkompilovaných souborů.

Nj, ale pokud zachováváš zpětnou kompatibilitu, tak se ti IMHO Java API stejně rozroste jako jakékoliv neobjektové rozhraní - jen se ten switch přesune z kódu aplikace mimo dohled. Ale to už je o tom, co chceš jako programátor "vidět". Já chci vidět, jak se ten který příkaz převede do assembleru.

drake127: Rozrůst se může, ale vždy v duchu toho návrhu. Bude-li třeba, vyčlení se nová třída, kde budu nové chování lépe zapouzdřeno. Switche se sice člověk úplně nezbaví (v některých speciálních případech ano), ale jeho použití lze eliminovat pouze a jen do okamžiku vytváření instance a co navíc - veškeré switchování nechat na vytvářeném objektu samotném, tj. na "volaném" a ne na "volajícím" (klient).
Takže zrovna v příkladu s těmi windows looky, by to bylo třeba tak, že by se zavolalo nějaké LookManager.getCoolestLook(), což by vracelo nejnovější použitelný Look. Nemusím dávat if, nemusím znát název knihovny a nemusím ani vědět, jaký rok je a že windows mají tolik a tolik looků

Je pravda, co říkáš - je to o tom, co zrovna člověk chce vidět... Ale vůbec, dost jiná koncepce a její využití...

Mám problém a potřebuji radu a nebo přímo pomoc.

K OpenGaming fóru nechci udělat stránky, ale spíše bych si představoval vstupní portál jako napříkald http://www.asrai.org

nevíte někdo zda je tohle featurka phpBB, případně zvlád by jste mi jí někdo do konce února udělat (s tím že přístupová hesla k doméně budu mít až na konci ledna, až se na mě převede)-

Díky za odpověď

Dalcor: Mno tohle je featurka phpBB Plus. Zkus vyhledat phpBB portál.
Vlasák: Konec, já s tebou stále souhlasím, ale furt se hádáme. Takže tentokrát - jo, máš pravdu.

Díkes