Entropia Universe will never be utilizing 64-bit Microsoft Window to the max!
Sigh, it's probably more interesting to get Entropia running natively (and fully utilizing) on 64-bit Windows first.... then they can worry about other platforms...
Entropia Universe, it's Client Loader and Voice chat, are all 32-bit applications, pure and simple, they cannot see nor use server grade PAE for 32-bit systems with that option or native 64-bit memory, well I should say 33~38 bits anyway (of the address space out of 64-bits). Which 33 bits is 8 GB RAM and 38 bits is 256 GB RAM (40 bits is 1 TB of RAM).
Something interesting to note is that even though you may have a 64-bit OS or at least think it's fully 64-bit, it's really not because if it was, everything would be 64-bit and not be compatible with the older 32-bit userland applications nor libraries.
Some of these high end video cards require a 64-bit OS so they can have more than 4 GB page switched (virtualized) dedicated RAM onboard, it swaps the contents back and forth in main memory to the card's memory, which is known as a "memory window" for video cards. Problem being, if you are using say editing software that is 32-bit and you use a card with 6 GB of RAM like say a Nvidia Quadro 6000 series card, you're not getting the full benefit of what that card can offer. You need to use a 64-bit application that can use that card to the max and use the full RAM you have installed as well.
This is true for Entropia Universe as well too, some of the high end designer cards are not meant for gaming, they have optimizations that are different than a gamer's card and also you run into the same problem, 32-bit app that can't see past 32-bit (4 GB RAM), doesn't do you much good.
Now, as a note about Microsoft Windows and Linux. Linux by default as you all well know doesn't run Windows executables by default, and it requires a sandboxed application that gives an application the impression it is running in what appears to be a Microsoft Windows environment, although, since WINE doesn't emulate MS Windows if mimics the Hardware Compatibility Layer (HCL for short) that speeds up the operations but scarifices stability for speed. Essentially what WINE does is convert between the two HCLs bidirectionally, meaning MS Windows HCL and the HCL of the Linux you just happen to be running.
The problem arrises when you use different revisions of WINE, different patches, different versions of the Linux, different editions, different distributions, etc. The biggest problem in WINE is that the HCL in Linux isn't standardized per version and per distribution. As a note, at current count, today, July 1st, 2012, there are over 4,000 distributions of Linux out there, many with X-Windows and GUI on top of it and some are just command line. Then to make matters worse, each version up from the distribution can make drastic changes to the system as a whole to make it more stable but that leaves the programmers of WINE scrambling to make sure it works on the major distributions.
As a rule of thumb, I only will use WINE on LTS based distributions because I know they aren't making drastic changes to the system that could cause a catastrophic effect on WINE. Also, as strange as this sounds, I don't use the latest drivers for the system, only what I find in the LTS repositories and the restricted drivers known to work on the LTS I am using. I make sure the WINE I used is also found in the repository, not an experimental or backport, those are trouble in the making.
I will put it this way, if you want the 32-bit compatibility mode like what you see in 32-bit Windows, it's best to use Linux distributions that are 32-bit and there is a good reason for it, it goes back to the HCLs. 64-bit HCLs are different than 32-bit HCLs, while WINE can have the WINE64B option installed so you can hop back and forth and act like you are using WOW64 in Microsoft Windows (WOW64 is Windows 32-bit usermode on Windows 64-bit system, required by some applications), it can be a bit more tricky because every time something majored is changed in Linux, the 64-bit version of WINE updates and patches lag behind the straight 32-bit, another thing to consider.
Let's say you have, 8 GB installed and pissed off you can't use it because you've installed the 32-bit version of Linux. Ah, there is a nice thing about Linux, go to your repository, refresh / reload it, then go search for "PAE", for kernel and header, install those, if all goes well when you reboot when you get to console and type, uname -a, it will tell you have the kernel PAE installed, which means you can access more than 4 GB of RAM. What does this do to the HCL you might ask for Linux? Well, as far as WINE is concerned, it doesn't see anything past 4 GB of RAM which means all your other Linux based applications that are PAE aware, which are most of them on a modern Linux OS can use that RAM as free as a breeze.
Note about Entropia Universe on Linux, recently I was asked to try to install and run EU 12.7 on Ubuntu 32-bit 12.04 "Precise"Desktop Edition. So, I downloaded both that LTS and the Ubuntu 32-bit 12.04 Studio Edition, which is the same except the kernel is a low latency coding for real-time multimedia production / editing. Currently, I have them installing on computers here at work. I go for testing of stability over performance (oddly enough to think that for using WINE).
There are very specific options you have to set in the winecfg and winetricks applications to set Entropia Universe to run correctly. Previously, I used Playonlinux and the Pol Helper plugin but it seems to run afoul in this new version of Linux (not surprised though).
Something interesting to note, Cry Engine 2, has support for native Shader Model 3 in DirectX 9.0c and Shader Model 4 in DX 10/10.1, however there is no direct support Shader Model 5.0 for DX11 in that version, there is however support for it in Cry Engine 3. Not to confuse anyone here but MindArk has said this before, numerous times, they only support the game engine capabilities in DirectX 9.0c mode, which means DirectX Shader Model 3.0 is used. The Shader Model conversion based on the HCL for WINE is a hybrid between Shader Model 2.0, 2.5 (unofficially released) and 3.0. Which means you might get certain features in Entropia Universe to look absolutely beautiful while others are just plain ugly. This is true for the rest of the HCL for DirectX, it's not fully implemented aka doesn't directly interface with your hardware to allow you the full experience you would on a native Microsoft Windows machine. That's what's going on.
There was a push to keep OpenGL and other libraries like that away from the kernel processes which means you keep it away from directly interfacing with the hardware while allowing some access to it, it's not full as compared to MS Windows. However, I don't agree with either Microsoft because of the sloppy coding techniques / practices they use and keeping certain libraries and APIs out of the core. Some are necessary, with the proper coding and techniques they can minimize the damage a hacker or application can do to the core of the operating system.
I've been fidding around with the Linux core for quite awhile and been rewriting the kernel to include OpenGL and CL, I've also been working on creating a DirectX like library with API for this distribution of Linux. I realize that the majority of distribution programmers would hate me if I put this design out there, simply because it goes against the tide and the thoughts of how Linux should operate. As I have said in many Linux forums is that Linux itself has a major issue in the credibility department. Even, from distribution to distribution the Linux command set changes, enough to slow you down if you install a new version. For example, some still use the old command like "su" for access of superuser while others use "sudo" or do as a superuser, while others have both but are used in a very specific manner. While I enjoy using the console to get the majority of my work done in Linux, as it's far more direct albeit slower than GUI. The GUI needs to catch up to the command line in terminal / console and be more ergonomic in origin. I don't see that, even in the Ubuntu 11.10 default interface was built for touchscreen such as a pad based computer, if you didn't have a touch screen it was more of a nuissance than anything. It was akin to the default "Ribbon GUI" on Windows 8, also a big time nuissance.
The reason why more companies don't do native applications has been answered already in my previous text above, it's the credibility issue, the 4000+ distributions, even the top 20 are different enough in programming to be a serious issue in stability of a blob download (meaning no source code to compile but an executable and libraries to go with it). That's just too much to deal with for most developers that want to take the easy way out as it is, do as little work as they can and reap the benefits. I am seeking to change that statistic, I want to see more people develop native games in Linux, whether it's GL or the DirectX like lib and API I am working on, doesn't matter to me. By making a Linux distribution that has tightly coupled drivers and applications written by me or people that I hire, if I start another company specific to work on this would be best. The difference between this distribution and the others is that while the download would be free as would the support for the common users, corporations and/or premium users could by support plans to get immediate resolution to their problems, for example mission critical events. The source code would be closed to the general public but open to a select few, such as hardware manufacturers so we can write good solid drivers and I could support their hardware before it hits the open market. Since the system would be tightly coupled, I could then get to writing a better version of what WINE is, not just by a HCL but a lot more could be fleshed out to work in unison with this brand of Linux. Since, I would be controling the source code and everything in the OS, it would lend a hand to stability to the compatibility of Microsoft Windows applications in a sandboxed environment. The idea is to take all the good parts of Playonlinux, WINE (itself) and winetricks and put it in one application would probably be a better idea.
Linux has come a long way from it's humble beginnings and it continues to get better slowly even with all those damn distributions out there. Previously, I was hyper critical about Ubuntu's failures but it appears they've turned over a new leaf with the Ubuntu Studio 12.04 LTS edition release, it does have it's problems but so does all OSes, I must say, it's pretty easy to use from using Linux for so darn long.
Once, this installs and I try to get in it, if I get it working I will post what I installed and what options I set to get into EU on this OS. If you want I can give you the details on the system accessories and drivers I am using so if you want to try it or have the same setup you can give it a go as well.
)
