Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AyZeeWitness (101)]

it actually worked, missions do load successfully now!
although i'm running it with Ypack, installing GE with UP 3.4 doesn't create the il2ge.ini file so something is wrong either on my end or something is broken

UPD figured it out, everything works now!

[hello]

Same here, with the new wrapper no crashes.

Thanks, Storebror!

[SAS~Storebror]

Alright thanks for the feedback.
Looks like it's really the calling convention change in 4.15 that kicked in here (__stdcall instead of __cdecl, resulting in a stack corruption when caller doesn't match the callees convention).

Time for a new Selector version.


Mike

[slibenli]

Hmm, something doesn't make sense. I've been using __stdcall all the time for all sfs functions except __SFS_openf from wrapper.dll precisely because it would crash otherwise (with 4.12 and 4.13).
See https://gitlab.com/vrresto/il2ge/-/blob/master/core_wrapper/sfs/sfs.cpp#L43
Very odd, or am I missing something?

Edit: I've just taken a look at the Selector code (from an older version I think). Unless I've overlooked something only SFS_open/SFS_openf are ever called.
My theory is now that in the older IL-2 versions SFS_close/read/lseek already were __stdcall with SFS_open/openf being the odd ones being __cdecl. And those were now changed to match the rest.
Does that make sense?

[SAS~Storebror]

It would make sense but actually in older IL-2 Versions the full set of functions (SFS_open, SFS_openf, __SFS_openf) was __cdecl and TD simply decided to change that to __stdcall.
The latest selector tried to mitigate that change, however while it appeared to be working well, there was potentially a stack corruption going on under the hood which could lead to a game crash in the long run.
Never witnessed it myself, even not in sessions of 2+ hours, but in theory __stdcall would expect the library to clean the stack on returning from a method call, which in the forwarded calls to SFS_open / SFS_openf methods in old IL-2 versions simply didn't take place.
More drastically, IL-2 GE immediately bugs out on that calling convention change, which probably is the best thing to happen as it pointed out an underlying issue that would otherwise have been left unnoticed for years to come.

Blame it on TD.
It's a very bad style to change the calling convention of an existing method "under the hood".
The right way would have been to give the new __stdcall methods a new name (preferably) or at least a different parameter set.
But I guess TD was well aware of the mess they created.

Long story short, the next selector will ship with different wrappers for "old" and "new" IL-2 versions as there's no way to overcome the calling convention issue in a single library.


Mike

[PO_MAK_249RIP]

Hı Slibenli I did lots of tests for you at the time but ran out of steam as nothing appeared to resolve the problem.
I wıll try this latest buıld and report back
Mick

[slibenli]

It would make sense but actually in older IL-2 Versions the full set of functions (SFS_open, SFS_openf, __SFS_openf) was __cdecl and TD simply decided to change that to __stdcall.

With older IL-2 versions you mean everything up to 4.14? So that would mean I have been using the wrong calling convention for SFS_read/lseek/close the whole time.

[slibenli]

Hı Slibenli I did lots of tests for you at the time but ran out of steam as nothing appeared to resolve the problem.
I wıll try this latest buıld and report back
Mick

Hunting down bugs can be a lot of work. Until the change which introduced the bug is found there will be no fix.  And the only way find it is to systematically test those builds, I'm afraid. Just to be clear - those builds I I listed aren't attempts to fix the bug. The purpose of testing these is to find the build which introduced the bug

BTW anybody who experiences this bug (at least 11 according to the survey) is also invited to test those builds.

[SAS~Storebror]

With older IL-2 versions you mean everything up to 4.14?

Yes, anything before 4.15.
4.15 is the version where TD decided to change the calling convention.
Out of nothing, for no good reason, without any notice dare I say.

So that would mean I have been using the wrong calling convention for SFS_read/lseek/close the whole time.

No. It's a mess.
SFS_read and SFS_lseek have been __stdcall all the time.
SFS_close according to my best knowledge is __stdcall from the very beginning as well, as it's using the same push/pop scheme for arguments.
Only __SFS_openf was __cdecl up to and including 4.14.1, and suddenly changed to __stdcall in 4.15.

That being said, the only method following the Win32 calling conventions actually was __SFS_openf.
SFS_read should be _SFS_read@12, SFS_lseek should be _SFS_lseek@12 and SFS_close should be _SFS_close@4.

With the introduction of 4.15 __SFS_openf changed from __cdecl to __stdcall, hence should be __SFS_openf@12 at least or even better, get a completely new name, but neither of this happened, so we were left in this trap layed out for us, maybe even intentionally.


Mike

[slibenli]

OK, so does that mean __SFS_openf exported from wrapper.dll will be __stdcall in the new Selector version (which would require changes in il2ge)?
My guess is not - after all it doesn't crash with the test wrapper.dll, but just to be sure.

[SAS~Storebror]

In the next Selector Version we will ship two different wrappers for "up to 4.14.1" IL-2 versions and "4.15 onward" versions.
On the "up to 4.14.1" version __SFS_openf will be __cdecl to retain compatibility with IL-2 GE while at the same time avoiding stack corruption with the "up to 4.14.1" il2fb.exe.
On the "4.15 onward" version __SFS_openf will be __stdcall to retain compatibility with 4.15+ il2fb.exe. This means that IL-2 GE will not work on 4.15 onwards as it stands.
To circumvent the latter, we could decide to introduce a new method just for IL-2 GE, let's say __SAS_openf, which would be __stdcall and would map to the right calling convention inside wrapper.dll internally.
That way IL-2 GE can become cross compatible for all game versions again, simply by replacing all calls to __SFS_openf by the newly introduced __stdcall __SAS_openf.


Mike

[AyZeeWitness (101)]

another question, how do i use the water mod with GE? doesn't do anything in my UP install...