The current work that Roderick describes on being able to load more DLLs into high memory is a step in the right direction, but can hardly be called a long-term solution. In the longer term, however, being able to use more than 4 GB of memory will be essential. The future lies in meeting new computing needs on modern hardware. This does not imply eCS developers should disregard backwards compatibility, but that it should not carry as much weight as it appears to do today. But as older applications gradually are phased out, surviving on backwards compatibility is a dangerous and non-sustainable long-term strategy. For many eCS customers this is an important issue. Backwards compatibility means, as Neil remarks, the possibility of running older applications. Quote from: Daniel Caetano on February 18, 2013, 01:23:52 pm Hi there.īackwards compatibility is one issue, adapting to new hardware and computing is another. allowing a slow transition between systems. In time, some original OS/2 services could be moved to the new kernel and privileges could be removed from the guest OS. PS: As an extra, this approach would provide a use for these "new OS/2 kernel projects", allowing them to improve faster.
Would that be possible (considering the available community/serenity resources)? At least, AFAIK, swapped data is not limited to 4GiB (Virtual Address Space should go up to 64TiB). I know it is not the same and the lower and upper shared/private arena problems would remain the same, but at least some things could use it. This would provide a usefull extra memory space. This virtual drive space could be used in two main ways:ī) Store temporary application files (like the "undo" files of Ceres Sound Studio!) The memory unnused by eComStation could be used as a virtual drive (emulation), which could be used as a normal harddisk by eComStation.
Well, at first, this will enable the underlying OS (OS Free, for instance) to access the entire memory.
#Ecomstation iso virus 32 bit
This way, I was thinking if it is not possible to make one of those "OS/2 5.0" projects, like OS Free, make its kernel 64 bits and configure its environment to support 32 bit systems (virtualization with almost full access to guest OS) and run eComStation inside of it. On the other hand, I think running an OS inside another full blown OS is somewhat annoying for daily use (one have to cope with problems and annoyances of both OSs). Several users are running eComStation inside a virtual machine and are ok with most of its limitations. I know it is not a simple limit to overcome, but I have been thinking of some measures to allow the use of extra memory, although it will be a limited one.
#Ecomstation iso virus 64 Bit
The biggest limitation eComStation has when working on 64 bit systems is the 4GiB barrier. Yesterday I was thinking about 64 bits and eComStation.
0 kommentar(er)
