Talk:Daodan DLL: Difference between revisions
RossyMiles (talk | contribs) (New page: Its cool that my version of Daodan got added to this page (I was going to add it myself, but I never got around to it) but I was wondering, why "Pelles C"? MinGW GCC is a very good compile...) |
(answers to Rossy) |
||
Line 1: | Line 1: | ||
Its cool that my version of Daodan got added to this page (I was going to add it myself, but I never got around to it) but I was wondering, why "Pelles C"? MinGW GCC is a very good compiler. As for assembly, both GCC and Pelles C support inline and external assembly (I don't know about MASM syntax, although MinGW's linker can take input from other compilers.) It doesn't really matter though as both compilers compile C99 and should be relatively compatible. | Its cool that my version of Daodan got added to this page (I was going to add it myself, but I never got around to it) but I was wondering, why "Pelles C"? MinGW GCC is a very good compiler. As for assembly, both GCC and Pelles C support inline and external assembly (I don't know about MASM syntax, although MinGW's linker can take input from other compilers.) It doesn't really matter though as both compilers compile C99 and should be relatively compatible. | ||
:-[[User:RossyMiles|rossy]] 11:22, 9 November 2008 (CET) | |||
According to SFeLi, GCC doesn't support fastcalls and Pelles-C does. He said, however, that we could stick to MinGW and emulate fastcalls with libraries written in ASM. I honestly am not familiar with the problem or the workaround, so I can't give a clear answer. Let's hope SFeLi is not dead, so he can comment on that when he's back. In the meantime, of course, just stick with MinGW, and keep those updates coming ;) | |||
:[[User:Geyser|geyser]] 14:54, 9 November 2008 (CET) | |||
---- | |||
The reason I changed C Daodan to replace binkw32.dll instead of adding vtuneapi.dll is that I had to patch a function that was called before vtuneapi was loaded. Turns out that the reason Alt-Tab and the Windows key didn't work is because the Oni developers specifically disabled them. (this is the part that prints "system sleep disabled, keystroke traps installed" in startup.txt.) The function that prints these is called before vtuneapi is loaded so I had to switch to replacing binkw32.dll. C Daodan still works as vtuneapi.dll however Alt-Tab and the Windows key don't work when it's used like this. | The reason I changed C Daodan to replace binkw32.dll instead of adding vtuneapi.dll is that I had to patch a function that was called before vtuneapi was loaded. Turns out that the reason Alt-Tab and the Windows key didn't work is because the Oni developers specifically disabled them. (this is the part that prints "system sleep disabled, keystroke traps installed" in startup.txt.) The function that prints these is called before vtuneapi is loaded so I had to switch to replacing binkw32.dll. C Daodan still works as vtuneapi.dll however Alt-Tab and the Windows key don't work when it's used like this. | ||
:-[[User:RossyMiles|rossy]] 11:22, 9 November 2008 (CET) | :-[[User:RossyMiles|rossy]] 11:22, 9 November 2008 (CET) | ||
Point taken about early DLL loading. One thing though: to avoid conflicts with previous versions of the Daodan, maybe prevent Oni from loading vtuneapi.dll, unless you're doing that already. And another thing, not like it really matters, but Iritscen has been nagging us about it, and just won't stop: our "press Shift at startup" feature is screwed up, and the reason SFeLi hasn't fixed it is because the fix has to come before vtuneapi.dll is loaded; would switching to binkw32.dll make it possible to fix that feature? Or maybe it's completely pointless, because the Daodan already has command-line parameters of its own (uncompatible with the in-engine dialog), and KeyConfig is more than enough to customize controls? | |||
:[[User:Geyser|geyser]] 14:54, 9 November 2008 (CET) |
Revision as of 13:54, 9 November 2008
Its cool that my version of Daodan got added to this page (I was going to add it myself, but I never got around to it) but I was wondering, why "Pelles C"? MinGW GCC is a very good compiler. As for assembly, both GCC and Pelles C support inline and external assembly (I don't know about MASM syntax, although MinGW's linker can take input from other compilers.) It doesn't really matter though as both compilers compile C99 and should be relatively compatible.
- -rossy 11:22, 9 November 2008 (CET)
According to SFeLi, GCC doesn't support fastcalls and Pelles-C does. He said, however, that we could stick to MinGW and emulate fastcalls with libraries written in ASM. I honestly am not familiar with the problem or the workaround, so I can't give a clear answer. Let's hope SFeLi is not dead, so he can comment on that when he's back. In the meantime, of course, just stick with MinGW, and keep those updates coming ;)
- geyser 14:54, 9 November 2008 (CET)
The reason I changed C Daodan to replace binkw32.dll instead of adding vtuneapi.dll is that I had to patch a function that was called before vtuneapi was loaded. Turns out that the reason Alt-Tab and the Windows key didn't work is because the Oni developers specifically disabled them. (this is the part that prints "system sleep disabled, keystroke traps installed" in startup.txt.) The function that prints these is called before vtuneapi is loaded so I had to switch to replacing binkw32.dll. C Daodan still works as vtuneapi.dll however Alt-Tab and the Windows key don't work when it's used like this.
- -rossy 11:22, 9 November 2008 (CET)
Point taken about early DLL loading. One thing though: to avoid conflicts with previous versions of the Daodan, maybe prevent Oni from loading vtuneapi.dll, unless you're doing that already. And another thing, not like it really matters, but Iritscen has been nagging us about it, and just won't stop: our "press Shift at startup" feature is screwed up, and the reason SFeLi hasn't fixed it is because the fix has to come before vtuneapi.dll is loaded; would switching to binkw32.dll make it possible to fix that feature? Or maybe it's completely pointless, because the Daodan already has command-line parameters of its own (uncompatible with the in-engine dialog), and KeyConfig is more than enough to customize controls?
- geyser 14:54, 9 November 2008 (CET)