Wine-Staging 4.20 Adds Undocumented D3D9 Internal Function For The Sims 2

[Weasel]

Really this shows that you are presuming the developer has done wrong.

Are you fucking stupid?

So let's say you are the developer.

Show me how you use this function that is undocumented. Right now. Show me some code. You idiot.

If it's undocumented how the fuck do you even know how to use it?

Also you wrong. The C++ old mangling stuff tells you its not a stdcall or cdecl its in fact a Microsoft fastcall don't know why a function that has no arguments.

Implemented as MS fastcall but that means by ABI eax is not stomped stopped unless function has return value. Welcome to hell being do not use function that not using a common calling convention either you just presumed it a common calling convention another Microsoft current documentation skips straight over since it internally used only they don't have to proper document it right.

fastcall has the same call-clobbered registers.

Next time, show some proof for your claims, since you made them. Not going to waste more time with someone as clueless as you.

Stop typing paragraphs without proof, like in this case, call clobbered registers for different calling conventions. They're all the same on 32-bit x86: eax ecx and edx are call clobbered, rest must be preserved. (in terms of general purpose registers)

[oiaohm]

Are you fucking stupid?

So let's say you are the developer.

Show me how you use this function that is undocumented. Right now. Show me some code. You idiot.

If it's undocumented how the fuck do you even know how to use it?

Number 1 is not the most complex function to call. You need to know zero arguments to call it.

https://sourceforge.net/p/dxwnd/discussion/general/thread/f1a764e1/#c756

Number 2 as shown here calling the function after changing result ion is a good way to kill some forms of game cheats.

Number 3 the fact it was void * return was documented in the old Microsoft headers.

From what wine has seen 90 percent of the application that use this function use it one very simple way.
void * returnval;
returnval=.Direct3DShaderValidatorCreate9();
free(returnval);//I cannot remember what the free is here but it takes like 5 seconds to work out what free you have to use from looking at memory leak.

Todo this code you really did not need to know any more than what was in the headers. Yes making return value null works for the majority of cases and that is what wine did.

Now sim 2 and games like it is where it gets tricky. This is one of the programs built with the early dx9 SDK where the static linked object inside that uses this function and the developers of that(Microsoft) knows what the return structure is and is using functions inside that returned structure that is not documented.

https://bugs.winehq.org/show_bug.cgi?id=46735#c4

That void * return structure in fact contains a pointer to 4 other functions. One you can know what it is because it points to something known ie the release(). The other 3 functions in that undocumented return structure are also undocumented.

Please note Microsoft current documentation says that Direct3DShaderValidatorCreate9() is not void * what for old systems is incorrect. Wine and mingw uses stdcall what is incorrect due to return value it does not make any difference.

When you link against the MS .lib files on the other hand Direct3DShaderValidatorCreate9 uses MS fastcall this does make a difference if you have a return value or not.

So Direct3DShaderValidatorCreate9 has always been documented sometimes that documentation has been correct currently the Microsoft site documentation is wrong. The return structure of that function that the void * return value points to has never been documented but some versions of the Microsoft documentation tell you what function to use to free it at this point you have everything in Microsoft documentation to call the function. Yes applications developers who have not been caught by the early dx9 sdk static object linking into their binary have not been using that structure they have just been freeing it.

Basically there is enough information for anyone to call Direct3DShaderValidatorCreate9 there is not enough use the returned structure of the function for what it can in fact do. Wine will have to work out enough of that return value structure to support the old programs caught by early Microsoft dx9 sdk.

fastcall has the same call-clobbered registers.

No I said Microsoft fastcall only clobbers ECX and EDX.

https://docs.microsoft.com/en-us/cpp/cpp/fastcall?redirectedfrom=MSDN&view=vs-2019

Its right here in the Microsoft documentation you have not read Weasel. EAX is only clobbered from a Microsoft fastcall when it has a return value.

Microsoft could in some ways fix the problem by changing in the .lib to stdcall like wine and mingw do but that also would block the old code for performance and anti-cheat from being able to free the return value and cause memory leak on older versions of windows.

[Weasel]

Number 1 is not the most complex function to call. You need to know zero arguments to call it.
https://sourceforge.net/p/dxwnd/disc...f1a764e1/#c756
Number 2 as shown here calling the function after changing result ion is a good way to kill some forms of game cheats.

Number 3 the fact it was void * return was documented in the old Microsoft headers.

That's not documented, that's just a declaration (in header). Documentation is a human-readable text that humans can understand so they know how to use a function.

No I said Microsoft fastcall only clobbers ECX and EDX.
https://docs.microsoft.com/en-us/cpp...N&view=vs-2019

Its right here in the Microsoft documentation you have not read Weasel. EAX is only clobbered from a Microsoft fastcall when it has a return value.

Microsoft could in some ways fix the problem by changing in the .lib to stdcall like wine and mingw do but that also would block the old code for performance and anti-cheat from being able to free the return value and cause memory leak on older versions of windows.

I don't see anything about call-clobbered registers in what you linked. The only thing about ECX and EDX mentioned is that they are the first two parameters, which is exactly what fastcall is about.

Every external function (one the compiler does not know the contents of), even one with zero parameters and no return value, will always clobber EAX, ECX and EDX. This applies to stdcall, thiscall, fastcall, etc on 32-bit x86. Period.

Please stop discussing in topics you have no clue of.

And btw I don't have to read anything, I work with this stuff. I know it.

[oiaohm]

That's not documented, that's just a declaration (in header). Documentation is a human-readable text that humans can understand so they know how to use a function.

Documentation did include how to clean up after calling it not exactly what it did.

I don't see anything about call-clobbered registers in what you linked. The only thing about ECX and EDX mentioned is that they are the first two parameters, which is exactly what fastcall is about.

That not how Microsoft writes it. The fact EAX is not mention is not modifed as such.

Every external function (one the compiler does not know the contents of), even one with zero parameters and no return value, will always clobber EAX, ECX and EDX. This applies to stdcall, thiscall, fastcall, etc on 32-bit x86. Period.

this is absolute wrong on key points.
https://en.wikipedia.org/wiki/X86_calling_conventions cdecl you are absolutely under windows and you call a function with no return and no parameters eax, ecx and edx are caller-saved so can be clobbered function but are to restored after call.
thecall is based off cdecl so caller-saved and restored
stdcall eax, ecx and edx are optional to be caller-saved and restored but don't have to be this is compiler choice.

32 bit ms fastcall no registers are caller-saved/restored and ecx and edx are the only ones trashed on 32 bit. Fastcall is callee saved and restored registers. So its the odd man out as the register save and restore has to exist in the called function.

You are crossing the 64 bit version of fastcall with the 32 bit. Where the RAX under 64 bit fastcall is open to be trashed along with a stack of other registers.

Nothing like having basics wrong Weasel there are differences between those calling conventions what is responsible for saving and restoring registers to prevent clobering.

[Weasel]

Documentation did include how to clean up after calling it not exactly what it did.

And that's all you need to know, since it still works, if you use it. (older programs compiled with it)

That not how Microsoft writes it. The fact EAX is not mention is not modifed as such.

No. You can take a look at GCC source code if you want.

this is absolute wrong on key points.
https://en.wikipedia.org/wiki/X86_calling_conventions cdecl you are absolutely under windows and you call a function with no return and no parameters eax, ecx and edx are caller-saved so can be clobbered function but are to restored after call.
thecall is based off cdecl so caller-saved and restored
stdcall eax, ecx and edx are optional to be caller-saved and restored but don't have to be this is compiler choice.

I think it's cute you don't even understand the terms you are using.

caller-saved means the caller saves the registers (duh!). Which means they are clobbered by the function. If you need to preserve EAX, ECX or EDX, they must be caller-saved, i.e. the caller must save them and restore later, if needed. Which is the complete opposite of your "summary".

callee-saved registers are those that are not modified within a function (and if they are, they are saved and restored within the function). EBX, ESI, EDI, EBP are those registers.

Thanks for, again, proving what I say.

[oiaohm]

No. You can take a look at GCC source code if you want.

Sorry the way Gcc does it and way Microsoft own complier does it is in fact different on ms fastcall is in fact different. Gcc presumes extra may have been clobbered.

caller-saved means the caller saves the registers (duh!). Which means they are clobbered by the function. If you need to preserve EAX, ECX or EDX, they must be caller-saved, i.e. the caller must save them and restore later, if needed. Which is the complete opposite of your "summary".

callee-saved registers are those that are not modified within a function (and if they are, they are saved and restored within the function). EBX, ESI, EDI, EBP are those registers.

This is what you get from looking at gcc code not how Microsoft complier is handling fast call. Caller saving registers that are not going to be overwirtten cost clock cycles. ms Fastcall is design to push as much as possible to the callee instead of the caller doing it. If like gcc you presume more is cobbered than what really is no harm as long as the callee side restores it. That is something you will notice with gcc and ms fastcall the callee restores EAX so EAX end up restored twice if you don't have a return value.\

This is one of the causes of performance difference between code build with gcc and code built with MSVC. Fastcall on functions with no return values is not as good under gcc as MSVC.

[Weasel]

Sorry the way Gcc does it and way Microsoft own complier does it is in fact different on ms fastcall is in fact different. Gcc presumes extra may have been clobbered.

It's not, else you wouldn't be able to build binaries with GCC for Windows. And you can, it's called MinGW or cygwin. I mean, Wine itself is built with it...

This is what you get from looking at gcc code not how Microsoft complier is handling fast call. Caller saving registers that are not going to be overwirtten cost clock cycles. ms Fastcall is design to push as much as possible to the callee instead of the caller doing it. If like gcc you presume more is cobbered than what really is no harm as long as the callee side restores it. That is something you will notice with gcc and ms fastcall the callee restores EAX so EAX end up restored twice if you don't have a return value.\

fastcall is a Microsoft thing. GCC has it for compatibility with Microsoft, so obviously it has to be the same.

Not gonna argue with more hocus pocus bullshit so suit yourself and stay ignorant.

[oiaohm]

It's not, else you wouldn't be able to build binaries with GCC for Windows. And you can, it's called MinGW or cygwin. I mean, Wine itself is built with it...

Unless there is a catch you have missed. Nothing in your standard application API/ABI that uses fastcall does not have a return value. So gcc being sightly off would not be noticed by most parties. Way gcc is slightly off only effects performance.

fastcall is a Microsoft thing. GCC has it for compatibility with Microsoft, so obviously it has to be the same.

Fastcall was not only a Microsoft thing. Borland register was also called fastcall. Gcc caller register saving and restore handling of msfastcall is a fall back to when gcc had borland register/borland fastcall support. Since its excessive belief of clobbered on the caller side it works at cost of performance in a 1 corner case.

See problem has to be the same. Issue here no it does not. Gcc recycled old code ending with msfastcall implementation that matches on the callee side and does not quite match on the caller side.

EAX is kind of clobbered because its the function pointer of the call. But by msfastcall callee functions not clobbering EAX means you can do a loop optimisation where a function is called multi times.

MOV eax, absolute_address(label)
CALL eax

If callee clobbers eax with return value you have to process the return value and do the mov again. If it does not have a return arguements you can just change the arguments and call without doing the move again. Yes depend on SEH to raise error instead of return value.

This is a very creative Microsoft performance optimisation gcc does not pick up and it only a factor in tight looped code. Its also why a fastcall without a return value can be slower than one with a return value. Why push and pop eax by the callee does not come for free on a fastcall function without a return value.

Presuming that compatible and the same is a big mistake. Wine does a lot of thing that are compatible with windows applications that is absolutely not the same as how windows does it.

Basically when you know msfastcall limitation you normally avoid doing it without a return value even if you just straight up ignore the return value windows API/ABI documented usage of fastcall always has a return value(this is no error it to avoid a problem). Its when you get into your own programs you get caught. mingw/cygwin is not going to have this problem most of the time. This does sometime turn out as the reason why a msvc built third party library is slightly faster than mingw/cygwin built one at runtime.

Weasel don't presume gcc implementation is always right when it comes to calling conventions in implementation sometimes it good enough and msfastcall is one of those good enough. With msfastcall 99.9 percent of msfastcall usage is going to be with a return value so there is very little reason for gcc developers to fix this difference to MSVC implementation just it catches you out with a performance variation in very rare cases and to get the performance boost you would have to add a code optimised to gcc that would be slowing built time down all the time.

There is many reasons why msvc produces code 1 to 2 times slower than gcc or llvm one of them is these stupidly rare coner case optimisations that other than really odd third party code is not used by anyone or really screws you over when you use a under-documented function that Microsoft has screwed the .lib file up on.

Caller side presuming EAX always clobbered by the callee makes your compiler faster to build with quite rare effects on performance.

[Weasel]

Unless there is a catch you have missed. Nothing in your standard application API/ABI that uses fastcall does not have a return value. So gcc being sightly off would not be noticed by most parties. Way gcc is slightly off only effects performance.

It's the same.

https://en.wikipedia.org/wiki/X86_calling_conventions#Register_preservation

Stop typing walls of text and show some proof. I won't bother with it unless you prove your claims.

[oiaohm]

It's the same.

That does not say its the same. It tells you when you build 64 bit code Microsoft complier now totally ignores the fastcall. Because it contains a horrible hack.

https://en.wikipedia.org/wiki/X86_ca...r_preservation

According to the Intel ABI to which the vast majority of compilers conform, the EAX, EDX, and ECX are to be free for use within a procedure or function, and need not be preserve

Please note vast majority of compilers. If you do find the intel documentation I do only have a offline copy in paper form it mentions the one exception the MSVC compiler 32 bit fastcall. Pity they don't have a reference to that documentation there or I could really shove it up you for being a moron.