Microsoft Exchange Forum

After doing some research, I realized that Exchange 2003 cannot even install on Wine. Here are the reasons:

1) Installation of Exchange 2003 requires that NNTP, SMTP, and the WWW services from IIS 6.0 or later be enabled and ready to go. But since IIS 6.0 is not available separately from the operating system as a download, we are stuck at square one.

2) A good portion of the applications in Exchange 2003 requires ASP.NET to run. But since ASP.NET is again a component of IIS 6.0, and since none of the .NET architectures can run on Wine at this time (2/22/2008), we have nowhere to go.

Even if we get something like Apache::ASP and attempt to duplicate the ASP functionality, we are still left with no .NET framework. So at this time, Exchange 2003 needs to be labelled as "Known not to work" due to its dependencies being unable to install.

As far as .NET framework on Wine is concerned, I wouldn't lose too quick hope.

.NET 2 IS installing (in some cases), is however crashing in my case after releasing the installer 3.1 (on XP, on win 2000 it is said to complete), this conflict between the 1st installation of the .NET and the installer is documented in some cases of the beta of .NET 2 on windows. Even if not completing, all files are there to do their work and are usually doing. Same behavior is currently seen on the last developments to CrossOver 7.

Haneder,

The type of behavior by .NET framework that you are describing is hardly cause for celebration. Any software can claim that "all files are there to do their work", but in this case all versions of .NET framework are KNOWN not to work.

Even if .NET framework can work somewhat reliably (remember, Exchange 2003 is a SERVER software, and working only half the time is absolutely unacceptable), there is still the issue of duplicating the ASP portion of the requirement. Apache::ASP could work, but unless we get it to a state where everything else is working fine, we cannot even begin to test it.

The software I am using is happy with the .NET as it is now, even if it is incomplete (it is working mostly based on Java, I didn't notice messages from the net aside from the licensing part on each start).
The problems that are causing me headache at the time are that some files end in the temp of linux, some in the temp of windows causing a problem of files not found when it happens to be saved in the unexpected location, C++ handling which is quite basic (you have to cross your problems that you don't get an error throwing you a C++ exception), threading in my case where using a second thread is causing a crash and problems of macros (script problems). Last time I tried the licensing server under cx, cx was cutting the line as soon as the availability of a license would be checked, although in a normal situation, it should be on all the time. To be able to reach it, I had to learn to configure the linux firewall too.

This heads up that to get it working and using, you have first really know what you are doing and what you'd better not click what you know doesn't (and be too in the knowledge that some functions are only working on the second launch). Basic functions are there. Trados is able to analyse a file and is able to translate using a translation memory. I'd better not ask too much for the moment with advanced functions as long as VBA does not get a little more stable (in word it is not working yet).

The .NET is not everything. It's just the door hiding a range of other issues, but even then it is not a reason to loose hope. I must however mention that I am not concerned by the overflow issues that some have in the most recent version of Wine.

I already promised one of my translator to try to install for him his version (older Trados) to test on cx 7.

Connecting to a memory server will not be tested on my side. I would have to have somebody with a server version which I don't know of so it will remain as standalone - thus I can't talk about connection issues.