It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
shmerl: OpenGL-next should be a major milestone to anticipate (for developers especially). So if you are interested in the progress, keep track of that.
avatar
Magmarock: I've used opengl for years it's not as good as directx and I doubt it ever will be.
I think you missed everything I said. Find information on OpenGL-next if you care to actually see the progress rather than complain.
Post edited January 09, 2015 by shmerl
avatar
Magmarock: I've used opengl for years it's not as good as directx and I doubt it ever will be.
Troll spotted.
Please don’t feed it. It’s not worth wasting anyone’s time.
avatar
Magmarock: I've used opengl for years it's not as good as directx and I doubt it ever will be.
avatar
vv221: Troll spotted.
Please don’t feed it. It’s not worth wasting anyone’s time.
I sure wish this forum had an "ignore" option. Found a request for it in the Community Wishlist:
http://www.gog.com/wishlist/site/allow_us_to_set_certain_forum_members_to_ignore

I voted for it.
Thank you for listening GOG to valid complaints
Thanks for all the knowledgeable fellow GOG-er's for coming up with viable alternative solutions to the issue.
GOG, Please keep this in mind however:
https://www.youtube.com/watch?v=IIAdHEwiAy8
The relevant message is at 2:38
Post edited January 09, 2015 by jorlin
Thank you GOG for listening.

Decisions like this make both you and your community stronger.

-
A Happy Customer
avatar
Magmarock: I've used opengl for years it's not as good as directx and I doubt it ever will be.
avatar
shmerl: I think you missed everything I said. Find information on OpenGL-next if you care to actually see the progress rather than complain.
Sigh, that is all he/she ever does in Linux related threads, throw around vague criticisms about Linux and/or OpenGL without any elaboration.
Post edited January 10, 2015 by king_mosiah
avatar
hedwards: Minor correction, Wine can handle 64 bit, sort of, it's just a real PITA to set up and not something that's done by default. In general, you don't want to go there if you don't have to, but it is possible.

I've done it and it's a pain that involves a fair amount of work in most cases.

http://wiki.winehq.org/Wine64
avatar
ssokolow: That just talks about building 64-bit Wine for Linux and I never claimed that wasn't possible. (I've used 64-bit Wine through Gentoo ebuilds, Ubuntu PPAs, and PlayOnLinux)

Emphasis mine.

64-bit Wine runs only on 64 bit installations, and at present only on Linux.
-- Wine FAQ, Section 2.5, Retrieved 2015-01-08 14:48 UTC-5
avatar
ssokolow:

I don’t know the exact details myself (Ken is the expert), but the answer is that it does not work, and probably never will. OSX has a ABI incompatibility with Win64 - OSX overwrites a CPU register that Win64 applications expect to remain untouched. Apple can’t change the ABI because there are already 64 bit OSX apps that expect things to work that way. A potential workaround may be to run Wine inside a CPU emulator like qemu, but that is anything but easy.
-- Stefan Dösinger, Thu Feb 20 07:28:07 CST 2014
avatar
ssokolow:

Actually, Alexandre is the expert, but this is my understanding as well.

Besides running under an emulator, it may be possible to wrap every call out to system libraries with code to save and restore the register. Or, if you prefer to think of it this way, the wrapper would be on exit from and entry back into native Windows binary code. This would be somewhat similar to what we do with stack alignment, although we have compiler help for that. Either way, that would probably impose a significant performance penalty.
-- Ken Thomases, Thu Feb 20 10:20:49 CST 2014
avatar
ssokolow:

This will actually be more complicated than stack alignment (__force_align_arg_pointer__) and the hook prologue. With stack alignment, Windows code is not allergic to 16-byte-aligned stack, it just fails to maintain it. So, it's sufficient for us to force 16-byte alignment when Windows code calls into Wine code. When Wine code calls out to Windows code, there's nothing we need to do. So, putting the attribute in the WINAPI declspec works.
-- Ken Thomases, Thu Feb 20 15:51:49 CST 2014
avatar
ssokolow: ...and so on.
The point I'm making is that it is possible for people that care enough about it, it's just a PITA and not terribly reliable.
avatar
king_mosiah: Sigh, that is all he/she ever does in Linux related threads, throw around vague criticisms about Linux and/or OpenGL without any elaboration.
Shame for them. I thought that after Ubuntu and Mint no one had the "too hard" excuse anymore. Definitely reeks of troll.
low rated
avatar
shmerl: I think you missed everything I said. Find information on OpenGL-next if you care to actually see the progress rather than complain.
avatar
king_mosiah: Sigh, that is all he/she ever does in Linux related threads, throw around vague criticisms about Linux and/or OpenGL without any elaboration.
I've only been on two Linux threads, and I have a low tolerance for BS. So many Linux fanatics are full of it.
Post edited January 10, 2015 by Magmarock
low rated
avatar
Magmarock: What the hell are talking about...? This isn't someone trying to code new emulator here this someone trying to manually extract data from an .exe this has nothing to do with dosbox and you're beating a straw man.
avatar
hummer010: This has a lot to do with dosbox. Or any other emulator / compatibility layer. It has nothing to do with Linux. If I want to use my own version of dosbox instead of the one included by gog, I need to extract the data from the .exe.
You can extract the data using install. You don't need to manually hack your way through it.
avatar
hummer010: This has a lot to do with dosbox. Or any other emulator / compatibility layer. It has nothing to do with Linux. If I want to use my own version of dosbox instead of the one included by gog, I need to extract the data from the .exe.
avatar
Magmarock: You can extract the data using install. You don't need to manually hack your way through it.
Really?!? I didn't know that.


There's a point here. You're missing it.
avatar
king_mosiah: Sigh, that is all he/she ever does in Linux related threads, throw around vague criticisms about Linux and/or OpenGL without any elaboration.
avatar
Magmarock: I've only been on two Linux threads, and I have a low tolerance for BS. So many Linux fanatics are full of it.
You also seem to have a low tolerance for ever being anything but vague it seems.
Post edited January 10, 2015 by king_mosiah
avatar
hummer010: This has a lot to do with dosbox. Or any other emulator / compatibility layer. It has nothing to do with Linux. If I want to use my own version of dosbox instead of the one included by gog, I need to extract the data from the .exe.
avatar
Magmarock: You can extract the data using install. You don't need to manually hack your way through it.
What?! Dosbox itself cannot be password protected under any circumstances. It is a violation of their GPL. Any archived games with Dosbox as part of the install cannot have a password of any sort blocking access to Dosbox itself. Can anybody confirm that Dosbox games are affected before I shoot off an email to the Dosbox team?
avatar
Magmarock: You can extract the data using install. You don't need to manually hack your way through it.
avatar
tremere110: What?! Dosbox itself cannot be password protected under any circumstances. It is a violation of their GPL. Any archived games with Dosbox as part of the install cannot have a password of any sort blocking access to Dosbox itself. Can anybody confirm that Dosbox games are affected before I shoot off an email to the Dosbox team?
I agree with Magmarock. Dosbox is not locked by password while it runs. Before running, you actually do not need to care about it. How GOG delivers the game including Dosbox is absolutely their own right. They could legally continue encrypting the installers if they so like. Fortunately they do not. But they could.

I'm sure that's what you will also hear from the Dosbox team. If not I would be interested in hearing the details of how this all works.

avatar
hummer010: ... This has a lot to do with dosbox. Or any other emulator / compatibility layer. It has nothing to do with Linux. If I want to use my own version of dosbox instead of the one included by gog, I need to extract the data from the .exe. ...
So install the game via GOG's installer for GOG's supported OS and then replace their DosBox with your DosBox. You don't need to access the installer in any other way than the intended one. Difficulties only come into play if you also use a Linux that is not supported.
Post edited January 10, 2015 by Trilarion
avatar
tremere110: What?! Dosbox itself cannot be password protected under any circumstances. It is a violation of their GPL. Any archived games with Dosbox as part of the install cannot have a password of any sort blocking access to Dosbox itself. Can anybody confirm that Dosbox games are affected before I shoot off an email to the Dosbox team?
Actually no, the GPL doesn't prevent it at all, at least not GPL v2. (for v3 it's a little more tricky)

You could have somebody take Dosbos source code load it with always online DRMs, include games encryption requiring a one time on-line unlock token to be run, or even streaming part the game content from an online server, and yet it would still be perfectly ok with the GPL as long as the person in question provide the source code of all his modifications.

The GPL doesn't forbid DRMs, encryption, restriction, whatever, it only says that you have to, if requested, provide the source code of the original program and of all the modifications you made to it.
Post edited January 10, 2015 by Gersen