Hmm. Czasy się zmieniają.
Obecnie pojemności cache procesora są większe niż pojemność starych dysków twardych, które z sentymentu trzymam w szafie.
Teraz w modzie są systemy 64 bit. Z jednej strony jest to moda, ale z drugiej konieczność.
Bardziej wymagające programy CAD, do obliczeń MES, renderingu wymagają gigabajtów pamięci, a jak pamiętamy limit pamięci dla systemów 32 bitowych to trochę ponad 3 GB ram.
Jeśli ktoś decyduje się na system 64 bit, to wybiera minimum 8GB ram, a 16GB jest standardem.
I to jest zasadniczo największa korzyść z 64 bitów, pomijając w pewnych warunkach kilkuprocentowy wzrost prędkości.
Standardem także są dzisiaj procesory wielordzeniowe.
Jak by więc nie popatrzeć mamy więc spory zapas zasobów systemowych.
Czy wobec tego (załóżmy czasowo, że jest to marnotrawstwo) trzeba się martwić maszyną wirtualną?
Według mnie największym zmartwieniem może być tylko wielkość obsługiwanej pamięci przez programy 32 bitowe.
Ale z tego co wiem Martin_S jest pierwszym, któremu "brakło bitów". Ale tylko z tego powodu, że zamienia jedną powierzchnie na kilka tysięcy mniejszych (proszę o wyprostowanie jeśli się mylę, lub bluźnierczo spłyciłem problem :D ).
Wróćmy teraz do problemu maszyn wirtualnych.
Obecnie programy piszę się w innych programach.
JAVA (która jest uznawana za nowoczesny język programowania) pracuje na ponad 3 miliardach urządzeń.
Programiści piszą program, który jest następnie kompilowany do kodu pośredniego, który może być uruchomiony na dowolnej platformie obsługującej JAVE.
Bo tak naprawdę wtyczka JAVY odpala maszynę wirtualną, która odpala pośredni kod.
Tracimy na obsłudze maszyny wirtualnej, ale zyskujemy przenośność programu.
No tak, ale zostawmy JAVE (niektórzy nie lubią jej za codzienne aktualizację :D )
Natomiast sam producent Windows od prawie 10 lat rozwija, przechodzi, promuje platformę .NET.
Znowu pójdę na łatwiznę, ale filozofia jest podobna do JAVY. Piszemy program (nawet w notatniku) i kompilujemy go.
Aby go jednak uruchomić potrzebne jest środowisko do uruchomienia - NET FRAMEWORK.
I jest to pewien rodzaj maszyny wirtualnej. W systemie LINUX odpowiednikiem jest MONO, które mimo, że nie jest wspierane oficjalne przez MicroSoft, ale znaczna ilość programów napisana pod Windows będzie działać na Linuksie.
Tak więc, jeśli program korzysta z tego środowiska to niezależnie czy będzie to program 32 bit, czy 64 bit, i tak odpali się maszyna wirtualna - środowisko uruchomieniowe.
Zakładamy jednak, że piszemy program bez .NET. Poprawnie napisany program będzie działał natywnie zarówno na systemie 32bit i 64 bit.
Bo najważniejszy problemem jest nie plik exe, ale obsługa bibliotek .dll.
Programy 32bit nie widzą bibliotek 64bit i vice versa.
Między innymi dlatego sterowniki 32bit nie działają na 64bit. Problemem są także programy antywirusowe.
Windows 64 bit używa dwóch katalogów do przechowywania bibliotek - jeden do wersji 32 bit, a drugi do 64 bit.
Jeśli tylko program 32 bit potrafi znaleźć własne biblioteki to wszystko jest OK.
Problemem są jednak stare aplikacje, które nie mogą znaleźć tych bibliotek ale wtedy przeważnie na bardziej wypasionych Windows (Pro, Ultimate) można odpalić maszynę wirtualną, przydzielić własną pamięć, a maszyna odpowiednio oszuka program tak, aby jednak znalazł te biblioteki.
ZWCAD+ używa NET FRAMEWORK, więc niezależnie czy 32 bit, czy 64 bit, coś więcej się uruchomi.
Środowisko .NET staje się coraz bardziej popularne.
Dużym jego atutem jest to, że możemy pisać różnych jeżykach programowania - Visual Basic, Delphi, C#. Nie trzeba się uczyć nowego języka.
ZWCAD+ od wersji 2014 potrafi także uruchomić nakładki opracowane w środowisku .NET poleceniem netload.
Opracowaliśmy jakiś czas temu kurs LISP, obecnie przygotowujemy się do rozpoczęcia kursu C# ze szczególnym uwzględnieniem CAD.
Tak więc niezależnie, czy 32 bit czy 64 bit, to każdy bardziej rozbudowany program wymaga platformy NET FRAMEWORK.
Pozdrawiam