Linux/Mac Wine/Crossover Headcount

[silentsteeple]

I can play on Windows, but I don't normally, and I probably won't be renewing my subscription until I can play on my Mac again.

[Jerusha]

Come on Guys, you all knew that AO only supports Windows. Whats the big problem now?

[Xyphos]

Come on Guys, you all knew that AO only supports Windows. Whats the big problem now?

the problem is, even if only windows is supported, the devs have now made it impossible to play on any other system that worked before.

I did some homework;
1) awsom DLL in the SDK that you link your application to is only 9mb.
2) the one AO ships with now, is 20mb.
which means, funcom has purposely modified the SDK's version of the DLL somehow, and it crashes when ran in WINE/Crossover.

3) moreover, the AwsomeProcess.exe isn't part of the SDK so that's another one of Funcom's doings, and Macrosun stated in IRC it was "to keep things isolated" even if the EXE is flagged and deleted as a virus.

4) when I ran a command-line viewer for when AO launches the awesom EXE, I noticed that all of the command-line arguments are in linux-style
eg, --enable-this-option which I think is a blatent mockery indeed, for something that "only supports windows"

imho, it would have been better to instead run the EXE as a thread from within the DLL, rather then as a seprate process, if the thread crashed, it could be restarted without effecting anything, and virus scanners would not be deleting important application Dependantcies.

[Jerusha]

1+2.) True. But the debug dll is 60mb. I guess they did a custom build with some debug symbol enabled. It is very hard to bump a dll from 9mb to 20mb with a few changes here and there. But I don't know what they did exactly.

3.) Eve Online does it the same way.

Maybe those pointers help ya:
http://support.eveonline.com/Pages/K...le.aspx?id=499
http://appdb.winehq.org/objectManage...sion&iId=18563

4.) Come on Xyphos.. --enable-option is not Linux exclusive :P. Get serious 8).


edit:
I compared both DLL, the original I got from awesomium sdk and the one from funcom.
The Funcom ones does contain a lot more stuff... like OpenGL Calls. The original does
not contain this. But I don't know if it is a custom build if they got Source Access. I have
the free sdk only.
http://img696.imageshack.us/img696/2160/awesomium.jpg

The Image marked with "O" is the original DLL, the one marked with F is the Funcom-DLL.


I understand your pain. But it is somewhat unfair to complain and to make funcom responsible for your preference not to use Windows. I would hate it though to loose you as a player in the Game.
regards

[Demoder]

the problem is, even if only windows is supported, the devs have now made it impossible to play on any other system that worked before.

Yes. They no longer support windows versions earlier than Windows XP. This means they dropped Windows 2000 and 9x, plus NT (if it ever ran on NT).
If you have paid attention, Microsoft stopped supporting these operating systems ages ago.

You need to go over to winehq and bump the bug ticket. It's a problem with Wine. AO was never (officially) intended to run on Wine.

I did some homework;
1) awsom DLL in the SDK that you link your application to is only 9mb.
2) the one AO ships with now, is 20mb.
which means, funcom has purposely modified the SDK's version of the DLL somehow, and it crashes when ran in WINE/Crossover.

As stated in the post above mine, most likely due to debug symbols. There's no way for us to know for sure, though.

3) moreover, the AwsomeProcess.exe isn't part of the SDK so that's another one of Funcom's doings, and Macrosun stated in IRC it was "to keep things isolated" even if the EXE is flagged and deleted as a virus.

Is Funcom to be blamed for false positives in crappy AV software too now?

4) when I ran a command-line viewer for when AO launches the awesom EXE, I noticed that all of the command-line arguments are in linux-style
eg, --enable-this-option which I think is a blatent mockery indeed, for something that "only supports windows"

Windows doesn't really have any style of command line switches. Microsoft use /X, but whoever makes the windows app has to implement parsing of command line options themselves. Maybe whoever implemented this parsing likes *nix' command line arguments in general, because they make more sense than the windows ones?
PS: To follow your argumentation technique, GNU/Linux stole that command line format from UNIX. Why doesn't GNU/Linux run native UNIX binaries?

imho, it would have been better to instead run the EXE as a thread from within the DLL, rather then as a seprate process, if the thread crashed, it could be restarted without effecting anything, and virus scanners would not be deleting important application Dependantcies.

See your earlier statement about how Macrosun said the separate process was for isolation. Again, false positives happen; Did you see the thread(s) about some AVs finding a keylogger in client.exe? A nice false positive, most likely caused by the new input system.

[Eiffel]

microsofts support for win2k ran out in the middle of this year. this means the free supply of security relevant patches. i stop here, rest of your post is at the same level.

[Demoder]

microsofts support for win2k ran out in the middle of this year. this means the free supply of security relevant patches. i stop here, rest of your post is at the same level.

And if you actually read my post, you'd see I didn't only mention win2k.
Please send me a PM with what you think is wrong in my above post, as I'm really interested in knowing.

[Eiffel]

indeed:

If you have paid attention, Microsoft stopped supporting these operating systems ages ago.

[Demoder]

Xyphos: If you actually want a solution to this problem, you should add a note about the winehq bug ticket in the OP to have people bump it so the winehq folks get around to it sooner. Seeing as you've already bumped it, but it's not in the OP yet, it's tempting to question your motives.

[Demoder]

indeed:

Long story short: You're not making sense, and we're derailing this thread. Please send me a PM if you still think my post is horrible.

[Lazy]

+.5 have a windows and a mac laptop and i use both.

[Ruffixx]

I'm just moderately technologically savvy, so for now I'm locked out of playing on my Mac in OSX.

However, I also have Bootcamp so I am still able to play on my MacBook (Late 2007) that way.

Once someone comes up with a pretty much idiot proof work around, I'll probably go back to playing in OSX. I don't mind logging into Bootcamp that much though, since when I have time to play these days (rare event), I play for long chunks of time, so rebooting isn't that bad.

[MajorOutage]

The Funcom ones does contain ... OpenGL Calls.

Now that is just comical.

[Vhax]

like OpenGL Calls

This isn't entirely strange.
Pretty much all of chromium is linked into that thing.
One of the things Google has been working on is GPU accelerating web rendering.
Then there's also features like WebGL they've been mentioning which likely also goes to OpenGL.

[Hacre]

Is Funcom to be blamed for false positives in crappy AV software too now?

They're to be blamed when their code makes itself look like a trojan.

Windows doesn't really have any style of command line switches. Microsoft use /X, but whoever makes the windows app has to implement parsing of command line options themselves. Maybe whoever implemented this parsing likes *nix' command line arguments in general, because they make more sense than the windows ones?
PS: To follow your argumentation technique, GNU/Linux stole that command line format from UNIX. Why doesn't GNU/Linux run native UNIX binaries?

*BBZZZZT*

The --double-dash --sentence-style of command line switch is a GNU standard, not a POSIX one. Linux makes itself compliant with POSIX by having -x -o type switches supported as well. In case you're not aware, GNU are one of the founding members of the FSF as well as a party carrying huge responsibility for founding Linux that we know today. They're also the originator for the GPL and its variants.

Oh and GNU/Linux can run native UNIX binaries provided you have the support compiled into the kernel however no one bothers since practically anything useful for UNIX has been ported over, or has the source code available to simply compile it on a Linux platform.

If you want to try and sound SMRT, make sure you have your facts straight.

Oh the irony.

Awesomium is based on WebKit and Chromium.

WebKit is a branch-off based on Konqueror's KHTML engine, KDE's default and opensource browser. Chromium is the non-branded opensource version of Google Chrome's browser, which is based on various opensource projects including WebKit (type "about:credits" into your browser).

In other words Awesomium wouldn't even exist if not for "these bearded guys who live in basements".

It's worth noting as well that by not releasing source for Awesomium they're in a bit of a legal minefield since webkit is LGPL licensed.

It's also worth noting that the wintard trolls should realise there are a great many components to Windows that wouldn't exist without *nix. Like the current TCP/IP stack, the kernel/driver/UI model, etc.

[DocJones]

It's worth noting as well that by not releasing source for Awesomium they're in a bit of a legal minefield since webkit is LGPL licensed.

from a PM discussion i had with Means about the issue:

I also feel for the non-windows people as the Awesomium version we are using is not open-source like the free one offered on his site...as such we can't "Hand it out" to that community even if we would like to.

[Lupusceleri]

from a PM discussion i had with Means about the issue:

The free one on his site isn't opensource either, you need to sign a contract to get access to its source.

[Jerusha]

It's worth noting as well that by not releasing source for Awesomium they're in a bit of a legal minefield since webkit is LGPL licensed.

Wrong. Terrible Wrong.
LGPL does not force you to release the Source Code of your product as long as you don't alter it.

[Vhax]

Wrong. Terrible Wrong.
LGPL does not force you to release the Source Code of your product as long as you don't alter it.

Not entirely, it quite depends on how you link it.
LGPL is mainly different from GPL in the scope it covers.
GPL covers an entire project, LGPL covers a binary.

Dynamic linking is how you hold LGPL at bay and prevent the license from spreading to your code.

Some projects have a 'static linking exception' clause added to their LGPL license though, to allow static linking.
In which case your statement would be right, only modifications would have to be released.

[Jerusha]

Not entirely, it quite depends on how you link it.
LGPL is mainly different from GPL in the scope it covers.
GPL covers an entire project, LGPL covers a binary.

Dynamic linking is how you hold LGPL at bay and prevent the license from spreading to your code.

Ahh, the old story. Static Linkage and LGPL^^.
This is an ongoing issue. If you where strict about it, a library using LGPL would not be allowed to use templates since the code for them is generated at compiletime. No way to link a template dynamic. QT has an excpetion for that included to the LGPL. But there are a lot of discussions around this issue and so far, non has come out with a clear "no static linkage allowed" so far.
Well okay, maybe it is some sort of minefield, but that lies in the nature of LGPL itself.
Well, how should a lawyer know about templates .
regards