MacOS & sigma

[WastingLight]

...

I've tried x64 only, but seeing how game runs on Win x64 systems without problems I didn't even think to try x32.
Tried x32 prefix as well - regrettably, same result.

About .asar files - make sure you "cd MedianXLLauncher" folder first, that worked for me.
After that you may see other exceptions when trying to change D2 path for example (that what didn't work for me on 3.0.4)

We'll see if Mac users are lucky in time.
Only couple of days left I'm more invested in this than ever.

Thank you mate! Fingers crossed, really hoping to play this weekend

[Solfege]

Update for Linux users (h/t SteelWings):

Got Launcher working again, and mod downloaded+installed via Laucher w/o problems (previously could load Launcher, but not download mod). Works only in Win 7 and Win 8/8.1 compatibility modes so far. WinXP is a non-starter (not supported) and Win 10 returns a critical error.

Steps taken:
- Updated WINE to verson 4.0-rc6 (Staging).
- Added components (via Winetricks): vcrun6, vcrun6sp6, vcrun2010, vcrun2017
- Installed corefonts (for whatever reason, this was a necessary component).
- Installed GlideWrapper (didn't seem to make a difference).
- Also tried random things, such as running vid test, removing spaces from file/folder names, etc. just to see if they had an effect (they didn't).
- Running via terminal makes no difference.

As of now, I'm also stuck on the "Failed to retrieve process" error. Gonna spend the evening working on this. Will post further updates if I make any progress.

[SteelWings]

As of now, I'm also stuck on the "Failed to retrieve process" error. Gonna spend the evening working on this. Will post further updates if I make any progress.

Hey, thanks for the update!

I've been debugging this whole thing as well for past day and I'm stuck at the same problem as well.
Running wine in debug mode revealed that the exception is thrown after call to advapi32:

0009:Ret advapi32.OpenProcessToken() retval=00000001 ret=100022c9
0009:Call advapi32.LookupPrivilegeValueA(00000000,1000bf94,0032f350) ret=100022ef
000d:Call advapi32.RegGetValueW(00000068,6dedb200 L"DefaultIcon",00000000,00000002,00000000,0008e300,0023e420) ret=6de2e9a5
0009:Ret advapi32.LookupPrivilegeValueA() retval=00000001 ret=100022ef
0009:Call advapi32.AdjustTokenPrivileges(0000047c,00000000,0032f358,00000010,00000000,00000000) ret=10002343
0009:Ret advapi32.AdjustTokenPrivileges() retval=00000001 ret=10002343
000d:Ret advapi32.RegGetValueW() retval=00000000 ret=6de2e9a5
...
0009:Call user32.MessageBoxA(00000000,1000bfe4 "Failed to retrieve process",1000bf70 "Median XL",00000010) ret=100022a0

As someone mentioned above this is most likely related to privileges failing to set properly, which is related particularly to SeDebugPrivilege (I assume).

Seeing how this issue is solved by using "Run as admininstrator" it probably means that some of the User Privileges are not set properly while using wine.
Maybe it's something to do with how a Wine user is created when application is run.
The user should (probably) have all the Administrator privileges, but for some reason they don't.
It may be a bug in Sigma's DLL library as well too.

Potentially it's may be a bug in Wine's implementation of token_adjust_privileges.

My C knowledge is lacking and I'm not sure I can dig this any further, but best solution we have for now is to report this particular problem to Wine's bug tracker and hope for a solution.
Or hope that this can be solved on MXL side and that team has resources to spend supporting Mac/Linux version. (which, unfortunately, is unlikely to happen, seeing how there are about 3 of us playing )

Well, Sigma is coming in less than 2 days now, this may have been fixed already in Sigma's DLL.

[Solfege]

Yeah, the privileges assumption is where I'm working from, too. But I have zero coding knowledge, so the best I can do to help is come at it from a component angle.

[SwineFlu]

I don't think it's a bug, you can't grant any new privilege to the process token, from MSDN: The AdjustTokenPrivileges function cannot add new privileges to the access token. It can only enable or disable the token's existing privileges. I'm assuming that in Wine by default administrator account doesn't have enough rights to grant this particular privilege or, to rephrase this, it's disabled by default for some reason (security measures?). You should try to find the way how to obtain SeDebugPrivilege for administrator user (or group), that is any process which is running under the administrator will be able to derive it.

Just my 2 cents, hope it will help you guys.

[SteelWings]

I don't think it's a bug, you can't grant any new privilege to the process token, from MSDN: The AdjustTokenPrivileges function cannot add new privileges to the access token. It can only enable or disable the token's existing privileges. I'm assuming that in Wine by default administrator account doesn't have enough rights to grant this particular privilege or, to rephrase this, it's disabled by default for some reason (security measures?). You should try to find the way how to obtain SeDebugPrivilege for administrator user (or group), that is any process which is running under the administrator will be able to derive it.

Just my 2 cents, hope it will help you guys.

Thanks, that's a solid tip!
I'll try to find what the actual state of User Privileges on launch is.

[SwineFlu]

Now that I'm thinking, the call to OpenProcess might cause this issue as well. So if you find out that you have a sufficient rights to grant SeDebugPrivilege and it still fails with the same error, in that case this aforementioned function call should be the problem if I have to guess. The reason why I'm bringing this winapi function again is because its requested desired access is set to PROCESS_ALL_ACCESS which is highly unnecessary and it might conflict with the security policy in Wine. If that's the case, there is nothing you can do except for modifying MXL.dll binaries or hoping that this inconsistencies are fixed in the Sigma. Well, maybe you can still adjust the policy accordingly to the required access, though I have no idea how it works in Wine cause I never used it.

[SteelWings]

...

Yes, that makes sense, because I found exact part where admin privileges are created: wine/server/token.c

const LUID_AND_ATTRIBUTES admin_privs[] =
{
{ SeChangeNotifyPrivilege , SE_PRIVILEGE_ENABLED },
{ SeSecurityPrivilege , 0 },
{ SeBackupPrivilege , 0 },
{ SeRestorePrivilege , 0 },
{ SeSystemtimePrivilege , 0 },
{ SeShutdownPrivilege , 0 },
{ SeRemoteShutdownPrivilege , 0 },
{ SeTakeOwnershipPrivilege , 0 },
{ SeDebugPrivilege , 0 },
{ SeSystemEnvironmentPrivilege , 0 },
{ SeSystemProfilePrivilege , 0 },
{ SeProfileSingleProcessPrivilege, 0 },
{ SeIncreaseBasePriorityPrivilege, 0 },
{ SeLoadDriverPrivilege , SE_PRIVILEGE_ENABLED },
{ SeCreatePagefilePrivilege , 0 },
{ SeIncreaseQuotaPrivilege , 0 },
{ SeUndockPrivilege , 0 },
{ SeManageVolumePrivilege , 0 },
{ SeImpersonatePrivilege , SE_PRIVILEGE_ENABLED },
{ SeCreateGlobalPrivilege , SE_PRIVILEGE_ENABLED },
};

Currently I'm manually building a new wine version with all those privs flagged as enabled, see if this work.

[SwineFlu]

Yep, seem like this privilege is excluded from the list of all of the available admin privileges.

[mortimer_85]

Hey guys. Just want to say that there is another wine using player around. Unfortunately I suck at the things discussed in this thread so much, that I cannot contribute to a solution, while hoping that you come up with a work around soon.
Really appreciate your effort.

Good Luck!