Patrik Stridvall ps@leissner.se writes:
In any case I think Vincent and Marcus is right, it should be have a WINAPI like in Vincent patch because otherwise the "DWORD service" parameter is not popped from the stack AFAICS.
No, it makes no difference whatsoever, the stack is restored from the context structure in any case.
Ah, OK. Wrong solution.
But still, shouldn't the "DWORD service" parameter be popped somewhere? I can't see any place where it is.
The only use of WINAPI would be to make winapi_check happy, but it would probably be better to teach it to not do that check for register functions.
VxDCall is the only register function that violates stdcall => WINAPI. But sure turning the check off in winapi_check is easy.
Patrik Stridvall ps@leissner.se writes:
But still, shouldn't the "DWORD service" parameter be popped somewhere? I can't see any place where it is.
It's already popped in the register context we receive, because we specified one argument in the spec file.
VxDCall is the only register function that violates stdcall => WINAPI. But sure turning the check off in winapi_check is easy.
It could be argued that no register function should be WINAPI, since they don't have to pop the arguments. But it's purely cosmetic either way.
I tried installing this game today, anyway it didn't install (That's what makes this job fun right?) .. I found that the installer did this, CreateFile(GENERIC_READ) SetAttributes(READ_ONLY), then it closed the file. Then it opened it again and tried to write into it. It was the license.txt file , interesting..
So I fixed the problem by forcing SetAttribute to do mode 022 (Group and all read only) .. But that doesn't seem like a proper fix to me.. I was thinking changes could be make to CreateFile() so it changes the attributes before opening the file , only if the person running wine is the owner of the file? Does anyone have any other thoughts?
Also, I guess this must mean that some versions of Windows don't enforce the READ_ONLY attributes ..
Daniel Walker