Czy biblioteka 64-bitowa może działać w aplikacji 32-bitowej? Na przykład mój GUI aplikacji używa 32-bitowego Qt. A moim rdzeniem biznesowym jest biblioteka 64-bitowa. System operacyjny jest 64-bitowy. Czy mogą razem pracować i jak? Dzięki.Czy 32-bitowe i 64-bitowe mogą współpracować ze sobą?
w skrócie: Nie można połączyć aplikację 32-bitowej do 64-bitowej biblioteki.
Można uruchomić aplikację 32-bitową, korzystając z 32-bitowych bibliotek współużytkowanych w 64-bitowym systemie operacyjnym (przynajmniej wszystkie popularne 32-/64-bitowe procesory, takie jak AMD, Intel i Sparc). Ale to nie dotyczy żadnych bibliotek.
Dłuższa odpowiedź: byłem zaangażowany (na obrzeżach) niektóre z zespołów, który zaprojektował 64-bitowego jądra systemu Linux dla x86. Krótko (w porównaniu z całym projektem dyskusje trwały kilka godzin), dyskusja na temat tego, jak można to technicznie zrobić. Krótkie podsumowanie tego jest takie, że w wersji 64-bitowej istnieją rejestry, które nie są dostępne w wersji 32-bitowej. Istnieje również problem adresów pamięci i dodatkowych 32-bitów w rejestrach. Wszystkie te mogą zostać rozwiązane, zakładając, że sama biblioteka "wie", że jest to 32-bitowa kompatybilna biblioteka. Ale wtedy mamy po prostu 64-bitową bibliotekę, która jest napisana jako biblioteka 32-bitowa, i trochę straciliśmy punkt.
„Więcej rejestry” mogą nie mieć zastosowania do niektórych procesorów, ale większe adres/bit zakres rejestrów zdecydowanie dotyczą WSZYSTKICH 32- i 64-bitowych procesorów kompatybilnych. Nie mam też pojęcia o żadnym pojedynczym procesorze, który umożliwia 32-bitowy kod wywołujący 64-bitową bibliotekę współużytkowaną lub bibliotekę statyczną. To po prostu nie działa, chyba że kod jest specjalnie napisany, aby poradzić sobie z tym, co jest sprzeczne z celem posiadania ogólnej 64-bitowej biblioteki do obsługi 32-bitowych aplikacji.
Edycja:
Wyżej omówione łączących jedną jednostkę wykonywalny np plik wykonywalny, biblioteka współdzielona lub biblioteka statyczna. To musi być wszystko "jedna bitness", albo 32 albo 64 - bez mieszania.
Podczas procesu, który komunikuje się z innym procesem (np. Aplikacja GUI, która wyświetla status z procesu innego niż GUI), o ile dwa procesy używają tego samego protokołu [i zazwyczaj IPC nie pozwala na przekazanie wskaźniki, tak więc konwersja 32-/64-bitowa nie jest tak dużym problemem], możesz mieć jeden proces, który jest 32-bitowy, a drugi 64-bitowy.
W systemach Amiga było kilka różnych binarnych kodów, które mogły uruchamiać pliki binarne zawierające 68k i kod PPC. Stuby zostały połączone, aby wykonać przełączanie kontekstu, gdy wykonywanie było uruchamiane z jednego procesora na drugi. Jednakże, jeśli dobrze pamiętam, obydwa działają w trybie 32b. – Jens
-1 "W skrócie NO." jest nieprawidłowe.wszystkie 32-bitowe programy w 64-bitowym systemie Windows ostatecznie korzystają z usług 64-bitowych, ponieważ są one uruchomione w 64-bitowym systemie operacyjnym. aby wypełnić lukę w 64-bitowej bibliotece, możesz użyć dowolnej liczby technologii, w tym COM. –
@Alf: COM to RPC. Za pomocą RPC możesz wypełnić lukę pomiędzy 32 a 57 bitami. To nie jest szczególne. W bibliotekach 64-bitowy system Windows wciąż jest dostarczany z 32-bitowymi wersjami swoich bibliotek (DLL) w podsystemie WoW, właśnie dlatego, że nie można mieszać bitness w jednym procesie. – MSalters
Jeśli używasz systemu Windows, aplikacja skompilowana dla 32b może działać na systemie hosta Windows 64b: spójrz na podsystem WOW64 wbudowany w 64b Windows.
Po tym, możesz nie miks mix skompilowany dla 32b z kodem skompilowanym dla 64b. Oznacza to, że biblioteka zbudowana dla 32b nie może być połączona z kodem 64b i na odwrót. (Różne konwencje telefoniczne, stos układ klatek, z wyjątkiem relaksu, ...)
Tak, ale to nie jest połączenie z biblioteką, to jest interfejs wywołań systemowych, który wywołuje wywołania systemowe z 32-bitowego kodu do jądra 64-bitowego. To zupełnie inna sprawa. (Napisane przed dodaniem drugiego akapitu, co wyjaśnia mój punkt widzenia) –
@MatsPetersson: OP nie wymaga "łączenia z biblioteką", nie ma wymogu wykonywania zadania X w sposób, który nie działa; wręcz przeciwnie, OP prosi o sposoby, które działają –
"Czy biblioteka 64-bitowa może działać w 32-bitowej aplikacji?" znaczy co? –
Tak, ale jest to poważny kłopot.
Najpierw jądro różni się od biblioteki. Zazwyczaj biblioteka jest widoczna w wirtualnej przestrzeni adresowej twojego procesu; dzieli się przestrzenią adresową z własnym kodem. Wywołanie procedury bibliotecznej jest po prostu wywołaniem podprogramu.
W przeciwieństwie do tego, aby żądać usług od jądra, Twój proces wykonuje specjalną instrukcję, aby wygenerować pułapkę. Ta pułapka powoduje, że procesor wykonuje pewne specjalne czynności, które obejmują zapisywanie rejestrów procesu i innych stanów w pamięci (lub w specjalnych rejestrach procesorów, do których normalnie nie można uzyskać dostępu), zmianę różnych trybów procesora, aby były odpowiednie dla jądra, oraz zmiana licznika programu tak, aby wskazywał instrukcje dla jądra. Następnie kernel działa.W tym momencie jądro może działać w trybie 64-bitowym, podczas gdy proces był uruchomiony w trybie 32-bitowym. Jednak jądro ma na celu świadomość tych różnic. Kiedy twoje jądro sprawdza twój proces, aby zobaczyć, o co prosisz, szuka informacji i struktur danych, wiedząc, że twój proces był uruchomiony w trybie 32-bitowym. Jądro może obsługiwać zarówno procesy 32-bitowe, jak i 64-bitowe, inaczej traktuje każdy typ procesu.
Zakłada to oczywiście, że 64-bitowe jądro obsługuje procesy 32-bitowe.
Zwykle, gdy wywołujesz bibliotekę, chcesz, aby był to ten sam tryb, co Twój kod, ponieważ normalne wywołanie biblioteki to tylko wywołanie podprogramu; nie generuje pułapki i nie zmienia trybów procesora. Jeśli wystąpiła krytyczna potrzeba wywoływania procedur w 64-bitowej bibliotece z procesu 32-bitowego, można utworzyć 64-bitowy proces pomocniczy. Twój 32-bitowy proces skompilowałby żądanie wywołania biblioteki i wysłałby to żądanie do 64-bitowego procesu pomocniczego przez pewną formę komunikacji międzyprocesowej. Ten proces pomocnika wywoła procedurę biblioteki i odeśle wyniki.
Oczywiście, powoduje to znaczny narzut związany z każdym wywołaniem biblioteki, więc jest to coś, co chcesz zrobić tylko wtedy, gdy istnieje wielka potrzeba i nie ma lepszej alternatywy.
+1 Aktualizuję, nawet jeśli opis sposobu wywołania jądra jest zbyt konkretny (jest typowy, ale w żadnym wypadku nie jest jedyną możliwością) –
Pracuję nad aplikacją, która robi dokładnie to. Rdzeniem aplikacji jest x64 (i używa Qt), ale musi się komunikować z niektórymi urządzeniami, dla których mam tylko 32-bitową bibliotekę od producenta. Sposób, w jaki go zaimplementowałem, to posiadanie dwóch aplikacji 64-bitowych na rdzeń i GUI oraz 32bity, które kontrolują sprzęt i komunikują się z głównymi aplikacjami za pomocą QSharedMemory. Obie aplikacje są oparte na Qt (odpowiednio 64 i 32 bitów).
Twoje jądro to jądro bitowe 32/64. Twoje jądro nie jest biblioteką. – MSalters
Dlaczego od razu myślisz o jądrze Linux i OS? Przez _ "jądro" _ może oznaczać własną bibliotekę, która jest swego rodzaju rdzeniem w jego aplikacji (tak, to jest rzeczywiście nieco źle sformułowany sposób, aby to nazwać, ale niektórzy to robią). Aby go połączyć, ma 32-bitową aplikację, która zawiera tylko GUI i oddzielną 64-bitową bibliotekę z pewną logiką. –
Zobacz ... Miałem rację, on właśnie nadużył terminu ... ':)' –