Looking at http://bugs.winehq.org/show_bug.cgi?id=17181 I get a feeling that we really need some testcases to verify we conform to the 16 bit MS-DOS API. Yeah, even though 16 bit is on the way out, there's still some use for a few win16 programs, and they use MS-DOS for file I/O.
We could merge in http://win16test.googlecode.com, but that requires the Watcom C compiler, and "apt-cache search watcom" still comes up empty (unless you're on Ark Linux, see http://www.openwatcom.org/index.php/Installing_Open_Watcom_on_Linux ) And the Linux build had problems building DOS apps last time I tried anyway.
But "apt-get install nasm" works great, so let's use it to run just a few crucial testcases, in particular, the one that keeps DOS apps from recursively deleting directories.
What I'm thinking is to add a configure check for nasm. If it's present, and the target is 32 bit Intel, dlls/winedos/tests would use it to assemble a few simple assembly testcases. The test cases would be run from a normal test case (so no deep integration), and only when running on a machine capable of running 16 bit code. I'll probably have an include file for routines to print PASS and FAIL, but otherwise it'll be very, very bare bones.
'Course, I have no idea when I'll have time to do this, but I imagine it won't be too complicated. It wouldn't bother me at all if somebody beat me to it. - Dan
"Dan Kegel" dank@kegel.com wrote:
Looking at http://bugs.winehq.org/show_bug.cgi?id=17181 I get a feeling that we really need some testcases to verify we conform to the 16 bit MS-DOS API. Yeah, even though 16 bit is on the way out, there's still some use for a few win16 programs, and they use MS-DOS for file I/O.
We could merge in http://win16test.googlecode.com, but that requires the Watcom C compiler, and "apt-cache search watcom" still comes up empty (unless you're on Ark Linux, see http://www.openwatcom.org/index.php/Installing_Open_Watcom_on_Linux ) And the Linux build had problems building DOS apps last time I tried anyway.
But "apt-get install nasm" works great, so let's use it to run just a few crucial testcases, in particular, the one that keeps DOS apps from recursively deleting directories.
Compiling DOS code to a .com file will produce a very small executable, then embedding it into the test, put it in %TEMP%, and exec should be trivial. No need for external tools IMO.
On Thu, Jan 29, 2009 at 9:20 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
Compiling DOS code to a .com file will produce a very small executable, then embedding it into the test, put it in %TEMP%, and exec should be trivial. No need for external tools IMO.
I thought of that, it's tempting.
But nasm is pretty common; I don't know that it would really be a burden to use it. And it would help testcase readability.
On Thu, Jan 29, 2009 at 9:34 PM, Dan Kegel dank@kegel.com wrote:
Compiling DOS code to a .com file will produce a very small executable, then embedding it into the test, put it in %TEMP%, and exec should be trivial. No need for external tools IMO.
I thought of that, it's tempting.
But nasm is pretty common; I don't know that it would really be a burden to use it. And it would help testcase readability.
and/or maintainability. Nobody likes having binary blobs next to the source code they supposedly came from.
"Dan Kegel" dank@kegel.com wrote:
Compiling DOS code to a .com file will produce a very small executable, then embedding it into the test, put it in %TEMP%, and exec should be trivial. No need for external tools IMO.
I thought of that, it's tempting.
But nasm is pretty common; I don't know that it would really be a burden to use it. And it would help testcase readability.
and/or maintainability. Nobody likes having binary blobs next to the source code they supposedly came from.
The exception tests in ntdll is a nice example how to do that without hurting readability and maintainability.
On Thu, Jan 29, 2009 at 9:40 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
The exception tests in ntdll is a nice example how to do that without hurting readability and maintainability.
Sure, it's doable, but after a while one's fingers begin to bleed. It all depends on how much code we're talking about, and how many people we expect to be able to write DOS testcases.
Do you see any harm in using nasm? I can't imagine it would be hard to update our list of build dependencies, and if anybody doesn't have it for some reason, no harm done... - Dan
Dan Kegel dank@kegel.com writes:
On Thu, Jan 29, 2009 at 9:40 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
The exception tests in ntdll is a nice example how to do that without hurting readability and maintainability.
Sure, it's doable, but after a while one's fingers begin to bleed. It all depends on how much code we're talking about, and how many people we expect to be able to write DOS testcases.
If there are really so many DOS test cases that it becomes a problem, then we can consider adding more infrastructure for it. I don't see that happening any time soon.
2009/1/30 Dan Kegel dank@kegel.com:
Do you see any harm in using nasm? I can't imagine it would be hard to update our list of build dependencies, and if anybody doesn't have it for some reason, no harm done...
Would gas work?
On Fri, Jan 30, 2009 at 1:37 AM, Henri Verbeet hverbeet@gmail.com wrote:
Would gas work?
Yeah, it's a little ugly, though.
Alexandre's right, we can add the machinery if/when we have so much code that the array of hex approach sags.
If gas is ugly and people are thinking about nasm, what about yasm? It is closer to the Intel syntax as far as assembly is concerned, and even VirtualDub has switched from MASM to YASM, mainly because they support VC debugging symbols along with regular MinGW ones.
On Fri, Jan 30, 2009 at 9:50 AM, Dan Kegel dank@kegel.com wrote:
On Fri, Jan 30, 2009 at 1:37 AM, Henri Verbeet hverbeet@gmail.com wrote:
Would gas work?
Yeah, it's a little ugly, though.
Alexandre's right, we can add the machinery if/when we have so much code that the array of hex approach sags.
On Thu, Jan 29, 2009 at 11:45 PM, Dan Kegel dank@kegel.com wrote:
On Thu, Jan 29, 2009 at 9:40 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
The exception tests in ntdll is a nice example how to do that without hurting readability and maintainability.
Sure, it's doable, but after a while one's fingers begin to bleed. It all depends on how much code we're talking about, and how many people we expect to be able to write DOS testcases.
Do you see any harm in using nasm? I can't imagine it would be hard to update our list of build dependencies, and if anybody doesn't have it for some reason, no harm done...
- Dan
How about we merge in the wine16 tests while we're at it?
On Fri, Jan 30, 2009 at 7:51 AM, Austin English austinenglish@gmail.com wrote:
How about we merge in the wine16 tests while we're at it?
That would be great, if someone wants to do it, but it's kind of a pain because it currently requires the windows version of the open watcom c compiler.
On Do, 2009-01-29 at 14:30 -0800, Dan Kegel wrote:
but that requires the Watcom C compiler, and "apt-cache search watcom" still comes up empty
There is a package with an installer:
http://www.openwatcom.org/ftp/open-watcom-c-linux-1.8RC3
THe release link in the near feature might be: http://www.openwatcom.org/ftp/open-watcom-c-linux-1.8
On Wed, Feb 4, 2009 at 3:24 PM, Detlef Riekenberg wine.dev@web.de wrote:
On Do, 2009-01-29 at 14:30 -0800, Dan Kegel wrote:
but that requires the Watcom C compiler, and "apt-cache search watcom" still comes up empty
There is a package with an installer:
That doesn't look like a .deb. Are they going to provide .deb's and .rpm's, too?
-
Alexandre Julliard -
Austin English -
Dan Kegel -
Detlef Riekenberg -
Dmitry Timoshkov -
Henri Verbeet -
King InuYasha