I'm trying to get WINE to work without the native ie8 workaround, as builtin WINE with Gecko is more equivalent to Edge, much more advanced. But some WINE logic hooking up Windows API calls to Gecko are not completely implemented.
Without having to do the ie8 workaround, ss13 devs won't have to care about ie8 backwards compatibility anymore. But it looks like they aren't much anymore anyway. I read that Colonial Marines now requires performance.now to get execution time for timing events, which should be at least ie10.
Also, using WINE it should be possible to run the BYOND client on not just Linux, but Macs and Androids as well. I've seen Diablo 2 run on ARM architecture using WINE.
Using wine debugging (no native ie8), I can see BYOND's splashscreen's progress bar doesn't appear to be bound or display, but pagerhome.html, jquery.js, pagerhome.js, pagerhome.css, and images like icons-friends.png are all downloaded and parsed, and a bunch of javascript executes without error. A DOMContentLoaded delegate is called, which I assume should make the pagerhome.html window appear and the splashscreen disappear.
The unimplemented cmdid trace messages don't appear to be relevant to the problem (e.g. IDM_PARSECOMPLETE and OLECMDID_HTTPEQUIV_DONE), and none of the fixme's or warn's appear to be the problem.
I'll be looking through the relay log and javascript code to see where exactly the new ieframe should be made visible... I'm not sure what interface isn't implemented sufficiently in WINE, e.g. IID_IHTMLWindow2 (I have no idea which right now). It could be that the issue is with progress bar event handling and doesn't have to do with the DOMContentLoaded event, I'm not sure yet.
What is needed are suitable Conformance Tests, small sample programs/tests written to demonstrate the WINE implementation conforms to Windows behavior.
ID:2668510
![]() Mar 30 2021, 4:04 pm (Edited on Mar 30 2021, 4:16 pm)
|
|
I compiled WINE with clang-8 using schroot. Wasn't too tough to do on Debian, but it took a while setting up scripts to streamline it.
The 'NewWindow2 Event' wasn't implemented in WINE: https://docs.microsoft.com/en-us/previous-versions// aa768336(v=vs.85) So I figured out where to implement that in WINE and did so. BYOND doesn't appear to change the ppDisp with a WebBrowser or Internet Explorer object (comes back NULL). Dang, worth a shot seeing if that was what it was. I suppose I could try the 'NewWindow3 Event' next, or look at other possibilities. There is a fixme:ieframe:WebBrowser_get_Parent that also looks promising to try. |
A fix for fixme:ieframe:WebBrowser_get_Parent didn't appear to improve things. And by fix I mean my best attempt to kludge something operational together without extensive background knowledge and experimental proof.
Lots of red herrings looking through the logs. WebBrowser_put_Visible(true) is called prior to WebBrowser_Navigate. So, I suppose I could read more about the expected behaviour here. A couple of these look promising to fix after some reading: 0024:fixme:ieframe:ClientSite_GetContainer (01510570)->(002176DC) An unimplemented bit in a QueryInterface call, I think I can fix this, puzzling why that interface would be queried on that object though: 0024:trace:mshtml:BindStatusCallback_QueryInterface Unsupported riid = {79eac9e4-baf9-11ce-8c82-00aa004ba90b} Also a javascript error I didn't notice before, that looks promising: 0024:trace:jscript:throw_error 800a03ed The javascript stuff is not a low hanging fruit for me to fix, I'm not well versed in this Gecko stuff. I should make clear that any patches I make are highly unlikely to meet the quality necessary for inclusion into Wine. I don't have MS Windows and have zero intention of installing a VM to test things on Windows, a necessary step in Wine development. The most I'll be doing is comparing to native DLLs. So if my kludges get things working and I share patches, others interested would have to patch then compile their Wine, not trivial to do, which involves a chroot/schroot and a workflow of 3x 32/64 bit compilations. |
When I try to replace jquery.js with an uncompressed version, BYOND replaces it. When I try to make it read only, BYOND aborts execution. I've not tried yet to use an inotify to replace it the moment after it is written, or I could replace it in the byond.exe GAMECONFIG resource.
I made mistake earlier, I assumed %APPDATA%/BYOND/pager/custom/* like pagerhome.html and jquery.js were downloaded. It turns out they are extracted from a resource in the byond.exe file:
I assume GAMECONFIG is compressed with a zip algorithm, when I compress %APPDATA%/BYOND/pager/custom/* it is ~144KB, the same size as the GAMECONFIG resource.
50 6c aa fe doesn't quite match known zip signatures though. The signatures in the ICON resources in byond.exe are as expected, so I don't expect any endianness wonkiness.
0x404 bytes are first read from the end of GAMECONFIG, I assume the header, and then the data appears to be copied backwards from that point. Once the data is copied, then the files are written to %APPDATA%/BYOND/pager/custom/
From what I read of the zip format, sometimes there is "header" information stored at the end of the file.
I've not been able to see a pattern matching a zip signature or header yet. If this turns out to be too difficult I'll try the inotify, or just make do without replacing jquery.js for now.
I figured I should document this effort somewhere for others interested, here is fine.