https://bugs.winehq.org/show_bug.cgi?id=38400
--- Comment #13 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Dmitry Timoshkov from comment #12)
(In reply to Bruno Jesus from comment #11)
It's a bug in the application, it works by a pure luck under Windows.
The app passes a not initialized ofn->lpstrFileTitle to GetSaveFileNameW(). Basically ofn->lpstrFileTitle points to the stack approximately 428 bytes above the current stack pointer, and since Wine's GetSaveFileNameW() uses more than 4096 bytes one of internal stack frames is guaranteed to be trashed after copying file name to ofn->lpstrFileTitle.
Same as bug 35200 then, at least I remember seeing a similar issue there and I attempted to create a patch [1] in order to mitigate the situation by checking how close the pointer is to the struct. But my tests on Windows led to crashes proving it would also overwrite the bad memory pointer, as you say it works by pure luck.
Sounds pretty similar.
The difference between these bugs is that the app in the bug 35200 calls GetSaveFileNameA while BDCraft Cubik calls GetSaveFileNameW. However both applications set ofn->lpstrFileTitle in a similar wrong way leading to stack trashing.
[1] https://bugs.winehq.org/attachment.cgi?id=52622&action=diff
I think that I've found a better (and easier) workaround.
A test shows that my workaround works also for the bug 35200 (and doesn't need any fancy checks).