Programowanie w Windows a Linux (środowisko Wine)

0

Posiadam trzy środowiska programistyczne:

  • Delphi 5
  • Delphi 1.0 dla Windows 3.x
  • Visual Studio 2005 (umiem programować tylko w C#)

Chodzi mi o wybór środowiska pod kątem kompatybilności tworzonych aplikacji z Linuxem (uruchamianie przez Wine).

Kiedyś miałem okazję spróbować uruchomić pod Linuxem jeden lub dwa programy przez siebie napisane w Delphi 5 i one działały. to było kilka lat temu, grubo przed wydaniem wersji 0.99, czy jakiejś tego typu zwiastującej zbliżanie się do wydania wersji 1.0 projektu Wine.

Obecnie nie mam Linuxa, ale chciałbym wiedzieć, jak ta kompatybilność wygląda. Delphi 1.0 wydaje się być najlepszym wyborem z tego powodu, że aplikacje i systemy 16-bitowe są chyba prostsze do emulacji niż 32-bitowe, ale jest taki problem, że w Delphi 1.0 są mniejsze możliwości niż w 5, ale do prostrzych programów wystarczające. Natomiast aplikacje działające w platformie .NET (Visual Studio 2008) moim zdaniem są w pewnym sensie "uwięzione" w środowisku Microsoftu, bo nie wiem, na ile jest dopracowana obsługa .NET (o ile istnieje) w Wine.

Jak obecnie wygląda kompatybilność programów pisanych w tych trzech środowiskach z aktualną wersją Wine? Programy z którego środowiska uruchomią się w Wine z największym prawdopodobnieństwem.
Czy to jest prawda, że prawdopodobieństwo bezbłędnego uruchomienia i działania programu 16-bitowego przeznaczonego dla Win16 jest większe niż 32-bitowego przeznaczonego dla Win32?

0

Cytat ze strony wyżej:

Aktualna wersja mono to: 1.9 Ma ona API w pełni zgodne z .NET 2.0. Zawiera też część elementów z .NET 3.5.

A co do tej teorii, że wine jest "bardziej" kompatybilne z aplikacjami 16-bitowymi od 32-bitowych - IMHO wątpliwe... Kto teraz używa aplikacji 16 bitowych? Raczej projekt wine koncentruje się na 32-bitowych programach...

0

Tylko jest taka jedna sprawa: Czy kompilator zawarty w Mono jest w pełni kompatybilny z Visual Studio 2005? Chodzi o to, czy kompilator C# z Mono bez problemu moze otworzyć plik z VS2005?

0

Jeżeli tylko to co napisałeś zadziała pod .NET 2.0 to pod Mono pójdzie na 100%. Jak nie, to pozostaje liczyć na to że to co użyłeś jest już w Mono zaimplementowane.

0

pierwsze wine to nie żaden emulator
A co do mono osobiście .NET nie używam ale wiem że nawet przy 2.0 mogą jakieś problemy wystąpić. A silverligth na *nix to jak na razie porażka

0

Silverlight 2.0 to dopiero nowość, poczekaj jeszcze na implementacje tego w mono.

A samo mono dla .NET 2.0 działa bardzo dobrze.

0

Jeśli chodzi o C#, to mnie interesuje .NET 2.0

0

Wine to implementacja win32api w środowisku Unix. Większość aplikacji 32 bitowych na ostatniej wersji działa poprawnie, nawet starsze gry. Nowe może i też, ale wydajność jest oczywiście mniejsza niż pod windows, a i mój komputer do cudów techniki nie należy. Czasami są jakieś troszeczkę odmienne reakcje programu. Natomiast co do programowania w delphi, to w ogóle nie interesuje mnie to środowisko, więc nie wiem, czy nie używa ono jakichś tam specyficznych dla siebie bibliotek i czy taki program nie będzie stwarzał problemów w Wine. Szczerze mówiąc spędzam prawie całe życie na Linuxie i oprócz devcpp nie znam innego programu, który byłby napisany w object pascalu, ale go nie testowałem. A nie, ostatnio hakerzy.net... działał.

Co do .NET i MONO, to w v. 1.9 występują kłopoty z uruchamianiem aplikacji pisanych w .NET 2.0. Być może w wersji MONO 2.0 zostanie to poprawione, ale głowy nie dam. Obecnie są implementowane elementy z najnowszej wersji neta, ale np.: implementacja WPF nie jest na dzień dzisiejszy planowana. Niestety zadaniem MONO jest ciągłe gonienie neta i zawsze będzie do tyłu. Natomiast program napisany pod MONO na pewno da się uruchomić w środowisku .NET. Jeśli nie masz Linuxa, a chcesz mieć możliwość testowania kompatybilności pisanych programów, to jest mono pod windowsa, a do pisania aplikacji darmowy sharpdevelop.

0

Wpadłem na jeden, może nienajlepszy (archaiczne metody programowania) pomysł, ale pomysł jest.

Na Linuxa istnieje emulator DosBox oraz Bochs. Oba są darmowe i w obu można bez żadnego problemu uruchomić Windows 3.1. W Bochs można uruchomić również Windows 98, ale on pracuje ociężale. Ktoś mi mówić, że w DosEmu ponoć da się uruchomić Windows 3.1.

Piszemy program i kompilujemy go pod Windows 3.1. Środowisko programistyczne nieważne, ważne, żeby otrzymać plik EXE 16-bitowy (uruchamialny pod Windows 3.1). W przypadku, gdy chcemy uruchomić pod Linuxem, czy jeszcze jakimś innym systemem (program DosBox podobno można skompilować na różne platformy), uruchamiamy emulator (moim zdaniem najlepszy DosBox, bo w nim dyskami stają się dowolne katalogi, więc wprowadzenie plików do wnętrza emulatora najprostsze), w ramach emulatora uruchamiamy Windows 3.1, a w nim nasz program. Wydaje mi się, że taki sposób sprawdzi się również, jak mamy jakieś starsze, 16-bitowe programy dla Windows, niekoniecznie przez siebie pisane.

W takim razie mamy trzy sposoby:

  1. Kompilacja do Win32 i uruchamianie za pomocą Wine
  2. Kompilacja do .NET i uruchamianie z wykorzystaniem Mono
  3. Kompilacja do Win16 i uruchamianie programu w prawdziwym(!) systemie Windows 3.1 wewnątrz emulatora Dosa lub komputera.
0

Chyba najgorszy pomysł w tym wątku. Aplikacje Win16 mają ogromne ograniczenia. Do tego emulacja... Wine to nie emulator a środowisko i zestaw bibliotek zapewniających sporą kompatybilność binarną. Boshs to pełny emulator bez wirtualizacji, z tego powodu jest najwolniejszą VM z powszechnie używanych. 16bit binarki można i na Viście uzyskać, starczy zainstalować stary kompilator Borlanda. Problem jest taki, że na procku 64bit aplikacji Win16 natywnie nie odpalisz. Cały proces jest najbardziej skomplikowanym i ograniczającym możliwości programiście z przedstawionych. I najważniejsza sprawa, co z licencją na Win 3.1?

0

Można by jeszcze spróbować kylix. Ale to już nie rozwijane i są problemy z instalacją na nowych distrach

0

Z Delphi problemu nie powinno byc, jezeli zwrocisz uwage na to, zeby nie uzywac tych rzeczy, ktore w Wine nie sa jeszcze do konca zaimplementowane albo nie zawsze dzialaja prawidlowo - ot chociazby gdi+, jakies interfejsy COM, DirectShow i windowsowe kodeki, globalne hooki, shell windowsa itd...

Problem tylko w tym, ze wiekszosc "programistów" Delphi uklada sobie komponenty na "formie" i o tym co to jest np. GDI+ nawet nie ma pojecia...

A tak w ogole, zamiast wymyslac jakies niestworzone rzeczy z aplikacjami 16-bitowymi na jakichs emulatorach dosu albo liczyc na WINE, nie lepiej wziac jakas biblioteke wieloplatformowa, jak chociazby wxWidgets albo QT?

0

Nie wiem jak to ma się do Delphi, bo jak już wspomniałem nie interesuję się tym. Jednak gdzieś tam zasłyszałem, że jest darmowe IDE do object pascala, Lazarus. Podobno jest nawet kompatybilne z Delphi, no i jest na linuksa i na windowsa. Jeśli masz czas, możesz się bliżej przyjrzeć temu środowisku.

http://www.lazarus.freepascal.org/

A tak na marginesie, może się to zmieniło, ale jeszcze około rok, półtora temu nie dało się uruchomić win3.11 na DosBoxie.

0

Jeśli zależy Ci na napisaniu rzeczywiście międzyplatformowego programu, użyj do tego prawdziwych międzyplatformowych narzędzi. Mam na myśli framework Qt: (http://pl.wikipedia.org/wiki/Qt), szczególnie wersje 4.x. Pisze się w tym przyjemnie, masz dostęp do wielu różnych modułów (obsługa sieci, xml, opengl, obsługa baz danych sql itd.), które działają na wszystkich obsługiwanych platformach! Wystarczy tylko skompilować program i jazda.

Jedynym wymaganiem dla Ciebie będzie nauczyć się C++, przynajmniej w stopniu bardzo podstawowym. Ale skoro znasz C#, powinno być łatwo ;)

Wirtualizacja softu ma dość spore ograniczenia i stosuje się ją przeważnie tylko do starszych aplikacji, które nie są już rozwijane/utrzymywane, a z jakichś powodów muszą działać.

0

Ale skoro znasz C#, powinno być łatwo

jak zna C# to łatwiej mu będzie zrobić przesiadkę na jave

1 użytkowników online, w tym zalogowanych: 0, gości: 1