Autor: Cezar Cichocki (CEZAR_at_psych2.psych.uw.edu.pl)
Data: Thu 15 Sep 1994 - 14:41:59 MET DST
VTAM!
> : On the average, Windows applications written to the Win16 API spend most of
> : their time making calls to the Windows kernel about 60% to 80% of all calls.
> : Most of these API calls are associated with the User Interface aspects of the
> : application, such as menus, displaying text, and scrolling.
> :
> : Wabi translates the Win16 API calls to Xlib calls,
>
> sam bym tak zrobil. Szumne slowo translacja oznacza ze jesli aplikacja
> wola API windowsa, to zostaje uruchomiona procedura WABI, ktora wkrotce
> wywola API X-win.
OK. Ale spojrzmy na format tzw NewEXE (czyli binaria Windowsowego):
___________________
| Native DOS code | -> tzn sprawdzenie czy wywolywany jest spod Windows
| | Niektore "madrzejesze" aplikacje potrafia sobie
| | same uruchomic Windows, przekazujac sie jako
| | parametr.
+-----------------+
| x86 code | -> Wlasciwy kod aplikacji, ALE w Windows oznacza to
| | tylko i wylacznie procedury obslugujace "wnetrze"
| | aplikacji + wolania odpowiednich zasobow (resources)
| | typu okna, atomizery itp itd.
| | Z grubsza przypomina to strukture pliku
| | skompilowanego pod DOS przez np Borland C
+-----------------+
| resources | -> czyli zasoby masci wszelakiej wyprodukowane przez
| | uzytkownika (choc mozna tez statycznie dolinkowac
+-----------------+ biblioteki DLL ktore zwykle (jak sama nazwa
wskazuje) sa "rezydentne" w tym systemie (?!) opr.
Zeby bylo smieszniej, do zbudowania funkcjonalnej aplikacji (tzn takiej
ktora po uruchomieniu wraca do systemu bez komunikatu bledy i padu "okien")
wystarczy tylko... czesc zwana "x86 code"! Mozna to np napisac w
assemblerze (masochizm!) i potraktowac duetem tasm/tlink.
I wtedy taki program nie bedzie posiadal zadnych (no, prawie) zasobow,
niec rysowal tylko bedzie rozpaczliwie usilowal zakonczyc prace.
Zakladam ze dzialanie programow "wspomagajacych wykonywanie aplikacji MS-
Windows na procesorach RISC" (chyba nikt mnie za slowko nie zlapie? :))
polega na:
1) Przejrzeniu bloku RESOURCES i przetlumaczeniu ich na odpowiednik w Xach
2) Zeskanowaniu bloku X86 CODE i zrobieniu czegosc na ksztal tabeli
zawierajacej odpowiednie odwolania do procedur Xowych.
3) Zignorowaniu czesci NATIV DOS
4) Uruchomieniu bloku X86 CODE na emulatorze CISC (takie cos jest zaszyte w
PENTIUM, ponoc).
Dlaczego procesor RISCowy nie moze samotrzec podolac wykonywaniu kodu? A
bo nalezalo by najpierw przeprowadzic (praktycznie rzecz biorac) KOMPLETNA
analize kodu w celu usunieci chociazby takiego "drobiazczku" jak...
roznica miedzy Big Endian i Little Endian. (to swap or not to swap?)
> : In RISC implementations of UNIX, Wabi uses a CPU simulator.
>
> zdaje sie, ze mowia o o tym, co my zwyklismy nazywac emulatorem.
O czym juz napisalem.
> : The simulator translates X86 instructions to the associated RISC instructions,
> : executes them and returns the appropriate value to the Windows application.
>
> A tu zabili klina. Ale jesli uwzglednic ze 'translate'=tlumaczyc, to mam
> wrazenie, ze ciagle opisuja emulator
Ha. Czyli czyzby on pobieral z segmentu kodu bajt, sprawdzal czy to nie
jest jakis rozkaz, a jezeli tak to sprawdzal w jakiejs tabeli ile i jakich
argumentow powinien takowy rozkaz posiadac, potem te argumenty pobiera,
potem przeklada to na ludzka mowe (tj kody dla RISCa), konwertuje pomiedzy
argumenty indianinami jezeli sa wieksze niz bajt, wykonuje operacje,
konwertuje wyniki pomiedzy indianinami zpowrotem i gdzies je tam zapisuje?
Uffff. To nie lepiej sobie kupic jakies 386SX? Powinno dzialac szybciej...
;-)
> Alternatywnie moze to oznaczac, ze wstawiaja rozkazy RISC w kod binarny
> x86. W swiecie PC to nic nowego. Tak dzialal emulator koprocesora:
Oj nie tak, nie tak! Np adresy skokow sa ustalane statycznie, wiec proba
"rozepchania" kodu skonczy sie w sposob wiadomy (a wlasciwie niewiadomy :))
Mozliwe, ze NewEXE jest NAJPIERW w calosci tlumaczony do jakiegos
pseudokodu (bo na nativ chyba nie ma sensu) a potem interpretowany.
> pomimo wyraznego rozkazu x87, assembler generowal w tym miejscu INT cos,
> przy wykonaniu programu wywolywana byla procedura emulatora, ktora w
> obecnosci x87 wstawiala poprawny kod operacji i wracala do programu.
Tzn inaczej. Proba odolania sie do nieistniejacego koprocesora powoduje
wygenerowanie przerwania 0x6, ktore emulatory przechwytuja i niecnie
podszywaja sie pod floatiing-point :-) A na marginesie: jak wiadomo w
swiecie PCtow mozna zamaskowac przerwanie niemaskowalne. Ot, mieli chlopcy
z Intela kupe zabawy przy projektowaniu tych cudeniek.
> Podobno cos analogicznego dziala teraz na Power PC w celu uruchamiania
> aplikacji Windowsa, tylko ze rozkazy x86 sa podmieniane na PPC.
Ale to zdaje sie idzie sprzetowo.
> Tylko, ze nie bardzo chce mi sie w to wierzyc, bo potencjalnych problemow
> (chocby rozna dlugosc rozkazow) jest cale mnostwo.
> Jaroslaw Lis
To mozna by bylo ominac za pomoca emulatora sprzetowego, oczywiscie przy
zalozeniu ze jedna aplikacja generuje polecenia TYLKO w jeden sposob.
Cezar
&&&
(o o)
+-------------------------------oOO--(_)--OOo----------------------
| It's my private opinion! U |
|-----------------------------------------------------------------|
| Cezar Cichocki | The best prevention against |
| Supervisor- network Administrator | viruses is not to buy a PC !|
| Dep. of Psychology |-----------------------------|
| Warsaw University POLAND | cezar_at_psych2.psych.uw.edu.pl|
|-----------------------------------|-----------------------------|
| also : cezar_at_plearn.BITNET, cezar_at_frodo.nask.org.pl |
-------------------------------------------------------------------
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 15:45:56 MET DST