2010-02-28 10 views

Odpowiedz

2
  • Systemy Windows i Linux używają różnych formatów kontenera do przechowywania kodu wykonywalnego (PE vs ELF).
  • Windows i Linux mają zupełnie inne API (z wyjątkiem trywialnych programów, które używają tylko CRT i STL)
  • Windows i Linux mają zupełnie inną strukturę katalogów

można napisać program, który można używać zarówno zestaw interfejsów API (na przykład, używając Qt), który może obsłużyć dowolną strukturę katalogów, ale nadal nie będzie można uruchomić tego samego pliku w obu systemach operacyjnych ze względu na różne formaty kontenerów.

Można to rozwiązać, używając numeru Wine.

5

Programy natywne nie są kompatybilne, ponieważ system Windows ma zupełnie inny zestaw interfejsów API niż system Linux. Jak wspomnieli inni, każda platforma używa również innego formatu wykonywalnego. Również obie platformy mają własny zestaw bibliotek, z którymi programy będą połączone i/lub współdzielone. Na przykład program Windows będzie zazwyczaj rozwijany w Visual Studio przy użyciu bibliotek specyficznych dla systemu Windows, takich jak MFC, Win32 API, itp. Biblioteki te nie są dostępne w systemie Linux, więc program nie będzie się nawet kompilował, chyba że zostanie podjęta odpowiednia kontrola - wykorzystywane są platformy (takie jak QT).

Jeśli jednak zachowasz ostrożność, możesz użyć bibliotek wieloplatformowych w swoim kodzie i możesz uzyskać ten sam program do kompilacji na obu platformach. W przypadku takiego programu należałoby ostrożnie umieścić wszelkie specyficzne dla platformy szczegóły (lokalizacje systemu plików itp.) W swoich własnych plikach. Następnie musisz ustawić odpowiednie instrukcje i/lub dyrektywy makefile, aby upewnić się, że odpowiednie pliki są zawarte w kompilacji dla każdej platformy.

Oczywiście, jeśli używasz języka "wieloplatformowego", takiego jak Java lub Python, i nie stosujesz w implementacji żadnego kodu specyficznego dla platformy, program może działać w obu środowiskach.

Uwaga Chociaż wykonywalne formaty są różne, niektóre programy opracowane na Windows mogą być wykonywane pod Linuksem używając emulatora o nazwie WINE.

+0

http: // sf.net/projects/line/"wykonuje niezmodyfikowane aplikacje systemu Linux w systemie Windows poprzez przechwytywanie wywołań systemu Linux" - odwrotność Wine. Nie utrzymuje się jednak przez długi czas. – ephemient

+0

Chłodny ... szkoda, że ​​go nie utrzymują. Czy próbowałeś, aby jakieś programy działały pod nim? –

+0

Nie, nie używam systemu Windows, więc nigdy nie próbowałem LINE. Słyszałem, że część kodu została złożona na http://umlwin32.sf.net/ (co, nawiasem mówiąc, jest jak odwrotność http://ring3k.org/), ale to też nie jest zachowane. Nie widzę też sensu: prawie wszystko na Linuksie ma dostępne źródło, więc łatwiej jest po prostu przenosić i rekompilować, niż pracować na takich hakach. – ephemient

0

C++ jest przenośny. Ale niektóre biblioteki C++ nie są. Jeśli program C++ korzysta z niektórych bibliotek, które nie są przenośne, program ten nie jest przenośny.

Na przykład program w języku C++ używa MFC do rysowania elementów interfejsu GUI, ponieważ MFC jest obsługiwany tylko w systemie Windows, więc tego programu C++ nie można skompilować ani uruchomić bezpośrednio na Linuksie.

+0

Aby być uczciwym: Prawdopodobnie może, szczególnie jeśli jest skompilowany/połączony z Winelib, który ma bardzo dobrą implementację MFC. (Chociaż twój punkt widzenia na temat przenośności bibliotek/API jest poprawny.) – greyfade

0

Każdy system operacyjny definiuje interfejs API. Jeśli zakodujesz wywołanie Win32 API, nie będzie tam na Linuksie. Jeśli kodujesz do interfejsu API POSIX, to nie wyskoczy na ciebie w systemie Windows.

Aby dowiedzieć się więcej na ten temat, pobierz znaczący program o otwartym kodzie źródłowym (na przykład Perl lub Python) i zobacz, jak jego skrypt "configure" umożliwia kompilację w dowolnym miejscu.

2

W skrócie,

Ponadto, nawet jeśli nie było to narzędzie do konwersji pomiędzy PE i ELF, instrukcje programowe niezbędne do interfejsu z systemem operacyjnym są całkowicie różne w systemach Windows i Linux. Tylko najbardziej ograniczony kod obliczeniowy (który wykonuje tylko obliczenia i nie wchodzi w ogóle w interakcję z systemem operacyjnym) może być przenoszony między systemami bez specjalnego działania. Jednak jest to rzadko wykonywane.

Wierzę, że niektóre wersje systemu Linux umożliwiają bezpośrednie ładowanie sterowników urządzeń zaprojektowanych dla systemu Windows bez ponownej kompilacji. Jest to jednak aplikacja o specjalnym przeznaczeniu, a technika ta nie jest powszechnie stosowana.

+1

Prawdopodobnie myślisz o http://ndiswrapper.sf.net/? – ephemient

1

Istnieją dwa główne powody.

Teoretycznie, ten sam program (kod źródłowy) dla niektórych języków, takich jak C, może działać zarówno w systemie Windows, jak i Linux. Ale kompilacja różni się tylko; oznacza to, że musisz skompilować ten sam plik kodu źródłowego dla każdej platformy.

Jednak w rzeczywistości każdy system operacyjny ma inny zestaw interfejsów API. I różne techniki, by szybciej wykonać pracę ... Które zazwyczaj przyciągają programistów do ich używania. I nie trzymają się norm, więc tracą przenośność.

To było dla programów natywnych ... W każdym razie, są języki Java i Python ... Są one naprawdę wieloplatformowe, ale trzeba poświęcić szybkość ze względu na przenośność.

0

To jest duży temat.

  1. Po pierwsze, systemy Windows i Linux nie są porównywalne z binarnymi. Oznacza to, że nawet najprostszy z programów nie zostanie rozpoznany z jednego komputera na drugi. Z tego powodu języki interpretowane, takie jak PHP, Perl, Python i Java stają się tak popularne, ale nawet one nie obsługują tego samego zestawu funkcji na każdej platformie.

  2. Uzależnienie biblioteki/obsługa systemu operacyjnego: Każdy znacznie bardziej skomplikowany program będzie musiał uzyskać dostęp do systemu w jakiś sposób, a wiele funkcji dostępnych w jednym systemie nie jest dostępnych w drugim. Istnieje milion przykładów; po prostu spójrz na to, aby uzyskać ekwiwalent pusty lub odpowiednik pustego systemu Windows. Przenoszenie poza aplikacje wspierające system operacyjny opiera się głównie na bibliotekach funkcji, a niektóre z nich nie są dostępne w obu systemach.

1

Nie jest zbyt pedantyczny, ale opracowanie programu różni się od jego zbudowania i wykonania. W wielu przypadkach program napisany w jednym systemie operacyjnym może być zbudowany i skompilowany do wykonania na innym. Inne programy, jak zauważyli inni, polegają na pewnej funkcjonalności zapewnionej tylko przez konkretny system operacyjny lub biblioteki rezydujące tylko w tym systemie operacyjnym. W rezultacie musi być zbudowany i uruchomiony w tym systemie operacyjnym.

Powiązane problemy