crazyc

It looks like listboxes should be handled in wlocale.cpp but this uses Delphi so the listbox class is TFileListBox (borland also uses TListBox) instead and it then sets it's wndproc to the real listbox one. Possibly the listbox wndproc should be set to TopLevelWindowProcEx using SetClassLong when dxwnd is loaded so when a listbox has a different class it's still caught. I did that https://github.com/otya128/winevdm/pull/1577/changes#diff-459db21540a970aa60a7a7104f95eda15b3aa669004f4a09de2b8332d2f42683R5307...

the parameter length remains the length of the ANSI version and the MCI_PLAY command truncates the midi file pathname at half its length Not quite. The game inserts the midi filenames into a listbox using LB_ADDSTRING. The filename is ansi but the listbox is unicode so it reads the first byte, sees no more valid characters and stops so the filename is one byte long. It then prepends the game path. The only way is see to fix it is to translate in SendMessageA between ansi and unicode for LB_ADDSTRING...

I debugged it in win98 and found that the aviwnd playback window is attached to the game thread and it's woken by messages sent to it. That won't work on any version of nt where mciavi creates a new separate thread for video decoding and playback even without the code I wrote above. It doesn't do anything with the messages so getmessage can probably be replaced with Sleep maybe for 100ms but I don't think that dxwnd can do it and would require patching. Edit: This change does work without patching....

I debugged it in win98 and found that the aviwnd playback window is attached to the game thread and it's woken by messages sent to it. That won't work on any version of nt where mciavi creates a new separate thread for video decoding and playback even without the code I wrote above. It doesn't do anything with the messages so getmessage can probably be replaced with Sleep maybe for 100ms but I don't think that dxwnd can do it and would require patching. Edit: This change does work without patching....

I debugged it in win98 and found that the aviwnd playback window is attached to the game thread and it's woken by messages sent to it. That won't work on any version of nt where mciavi creates a new separate thread for video decoding and playback even without the code I wrote above. It doesn't do anything with the messages so getmessage can probably be replaced with Sleep maybe for 100ms but I don't think that dxwnd can do it and would require patching. Edit: This does work. Handle exceptions and...

I debugged it in win98 and found that the aviwnd playback window is attached to the game thread and it's woken by messages sent to it. That won't work on any version of nt where mciavi creates a new separate thread for video decoding and playback even without the code I wrote above. It doesn't do anything with the messages so getmessage can probably be replaced with Sleep maybe for 100ms but it don't think that dxwnd can do and it would require patching. Edit: This does work. Handle exceptions and...

I debugged it in win98 and found that the aviwnd playback window is attached to the game thread and it's woken by messages sent to it. That won't work on any version of nt where mciavi creates a new separate thread for video decoding and playback even without the code I wrote above. It doesn't do anything with the messages so getmessage can probably be replaced with Sleep maybe for 100ms but it don't think that dxwnd can do and it would require patching. Edit: This does work. Handle exceptions is...

I debugged it in win98 and found that the aviwnd playback window is attached to the game thread and it's woken by messages sent to it. That won't work on any version of nt where mciavi creates a new separate thread for video decoding and playback even without the code I wrote above. It doesn't do anything with the messages so getmessage can probably be replaced with Sleep maybe for 100ms but it don't think that dxwnd can do and it would require patching.