Re: Wine VM86 exception handling bug?
On 6/5/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: I'd rather we got out of the habit of doing this seeing as I think git can deal with binaries better than cvs can. There is no point in storing the binaries in the *source* tree, besides tiny .com file which shows the bug shouldn't take more than 100 bytes of an array in the .c file. Sure it might be small, but it's still a binary no matter how we store it. It's not more useful as an array than as a true binary file on disk. Why obfuscate and expand it by embedding it into a text file? thanks -mike
Re: Wine VM86 exception handling bug?
Mike Hearn wrote: Sure it might be small, but it's still a binary no matter how we store it. It's not more useful as an array than as a true binary file on disk. Why obfuscate and expand it by embedding it into a text file? An LGPL'ed binary is a bit of a contradiction, isn't it? Mike
Re: Wine VM86 exception handling bug?
I believe it is better to store binaries as arrays and use temporary files than drop many small .com binaries all over the code tree (for now I have 3 test programs about 30 bytes each). It is possible to comment/disassemble test cases instruction by instruction, if needed. Also, not everyone can use git, and I believe diff/patch would fail to produce patchable diffs with binary files in them. Mike Hearn wrote: On 6/5/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: I'd rather we got out of the habit of doing this seeing as I think git can deal with binaries better than cvs can. There is no point in storing the binaries in the *source* tree, besides tiny .com file which shows the bug shouldn't take more than 100 bytes of an array in the .c file. Sure it might be small, but it's still a binary no matter how we store it. It's not more useful as an array than as a true binary file on disk. Why obfuscate and expand it by embedding it into a text file? thanks -mike
Re: Wine VM86 exception handling bug?
Am Montag, den 05.06.2006, 11:58 +0100 schrieb Mike Hearn: On 6/5/06, Robert Shearman [EMAIL PROTECTED] wrote: It depends whether it's in a convenient form. For a 100-byte COM file, it is probably already in its most convenient form. If, like Rob, you are an i386 ninja master who wields a disassembler as most of us wield a knife and fork then yes maybe :) For the rest of us source code can be occasionally convenient chuckle bin86 (BCC, together with as86 and ld86) might help wine. Bruce Evans C Compiler can create COM-Files Updates are done by Robert de Bath Homepage: http://freshmeat.net/redir/bin86/743/url_homepage/~mayday -- By By ... ... Detlef
Re: Wine VM86 exception handling bug?
I used nasm and hiew. There is no point in adding additional tools dependencies. Anyway the test codes wouldn't be changed somehow often. And anyway I'm already submitted patch :) Detlef Riekenberg wrote: Am Montag, den 05.06.2006, 11:58 +0100 schrieb Mike Hearn: On 6/5/06, Robert Shearman [EMAIL PROTECTED] wrote: It depends whether it's in a convenient form. For a 100-byte COM file, it is probably already in its most convenient form. If, like Rob, you are an i386 ninja master who wields a disassembler as most of us wield a knife and fork then yes maybe :) For the rest of us source code can be occasionally convenient chuckle bin86 (BCC, together with as86 and ld86) might help wine. Bruce Evans C Compiler can create COM-Files Updates are done by Robert de Bath Homepage: http://freshmeat.net/redir/bin86/743/url_homepage/~mayday
Re: Wine VM86 exception handling bug?
Mike Hearn [EMAIL PROTECTED] wrote: On Fri, 02 Jun 2006 08:01:55 -0700, Dan Kegel wrote: You can embed a trivial DOS executable as data in the .c file I'd rather we got out of the habit of doing this seeing as I think git can deal with binaries better than cvs can. There is no point in storing the binaries in the *source* tree, besides tiny .com file which shows the bug shouldn't take more than 100 bytes of an array in the .c file. -- Dmitry.
Re: Wine VM86 exception handling bug?
On Fri, 02 Jun 2006 08:01:55 -0700, Dan Kegel wrote: You can embed a trivial DOS executable as data in the .c file I'd rather we got out of the habit of doing this seeing as I think git can deal with binaries better than cvs can. thanks -mike
re: Wine VM86 exception handling bug?
Andrey wrote: My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 would restore vm86 registers correctly. I think i know what is the problem; however, I lack experience to fix it myself :) I need help; any hints would be appreciated. How about writing a conformance test that demonstrates the problem? That will help focus discussion and energy on it, and keep it from coming back. Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Wine VM86 exception handling bug?
Dan Kegel wrote: Andrey wrote: My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 would restore vm86 registers correctly. I think i know what is the problem; however, I lack experience to fix it myself :) I need help; any hints would be appreciated. How about writing a conformance test that demonstrates the problem? That will help focus discussion and energy on it, and keep it from coming back. Thanks! - Dan I would be happy to do it. Unfortunely, I cannot imagine how to implement such test: 1) DOS code needed - it would need binary or some sort of source to be compiled prior to test or some temporary file with a binary 2) method to catch failure inside of ntdll 3) maybe something else... It is just not seems to be possible to do all this inside of some .c file. Hmm, is there any test for kernel or winedos at all?
Re: Wine VM86 exception handling bug?
On 6/2/06, Andrey Turkin [EMAIL PROTECTED] wrote: How about writing a conformance test that demonstrates the problem? I would be happy to do it. Unfortunely, I cannot imagine how to implement such test: 1) DOS code needed - it would need binary or some sort of source to be compiled prior to test or some temporary file with a binary You can embed a trivial DOS executable as data in the .c file 2) method to catch failure inside of ntdll I'm sure you can work something out. At the very least, you can check that the DOS executable runs ok. It is just not seems to be possible to do all this inside of some .c file. Hmm, is there any test for kernel or winedos at all? If not, there sure ought to be... - Dan
