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
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?
On 6/2/06, Andrey Turkin pancha@mail.nnov.ru 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:
- 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
- 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
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
"Mike Hearn" mike@plan99.net 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.
On 6/5/06, Dmitry Timoshkov dmitry@codeweavers.com 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
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
Mike McCormack wrote:
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?
It depends whether it's in a convenient form. For a 100-byte COM file, it is probably already in its most convenient form.
On 6/5/06, Robert Shearman rob@codeweavers.com 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>
thanks -mike
Am Montag, den 05.06.2006, 11:58 +0100 schrieb Mike Hearn:
On 6/5/06, Robert Shearman rob@codeweavers.com 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
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 rob@codeweavers.com 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
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 dmitry@codeweavers.com 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
-
Andrey Turkin -
Dan Kegel -
Detlef Riekenberg -
Dmitry Timoshkov -
Mike Hearn -
Mike McCormack -
Robert Shearman