Hello, By accident, I removed the emails of the thread I started, but I'll look it up if necessary; I found this old wine issue of some time ago.. I think the patch it has there could be helpfull http://winehq.org/?issue=229#About%20Converting%20W-%3EA%20Calls However, I don't know how to make simple tests.. as I'd really need to test wether the code I write works, and works properly :p How do I write tests for that? I'm running linux (in practice, I never boot into windows) so how should I do this (testing without windows environment)? How are tests supposed to run? I hope you can give some clues on that; I found there are many W->A calls in dlls/winmm/winmm.c (according to the janitorial page) so I might start there (hoping not all of them are so tricky ;) ) Thanks for suggestions on this, Joris
However, I don't know how to make simple tests.. as I'd really need to test wether the code I write works, and works properly :p
The best way to test the functionality of a certain api function against windows is to read the msdn docs on that function. There are certain easy things to check like the error codes that are either returned or set using SetLastError (and are read using GetLastError.) The docs will also tell you pretty precisely what the function should and should not do, and you write the tests to make sure that the functions do what they're supposed to do. A lot of the times, msdn docs will have example code and will usually show the expected output (when necessary.) You can test against this output to see if the results are the same. Some api's cant really be tested with wine's testing system because the effects may be visual etc, so the way to test that is to run the program and see if the visual change coincides with the way the program runs in windows. If you dont have a windows install to run the program from, I'm sure that someone on wine-devel can run the program for you. On Tue, 31 Aug 2004 11:10:57 +0200, Joris Huizer <jorishuizer(a)planet.nl> wrote:
Hello,
By accident, I removed the emails of the thread I started, but I'll look it up if necessary; I found this old wine issue of some time ago.. I think the patch it has there could be helpfull
http://winehq.org/?issue=229#About%20Converting%20W-%3EA%20Calls
However, I don't know how to make simple tests.. as I'd really need to test wether the code I write works, and works properly :p
How do I write tests for that? I'm running linux (in practice, I never boot into windows) so how should I do this (testing without windows environment)? How are tests supposed to run?
I hope you can give some clues on that; I found there are many W->A calls in dlls/winmm/winmm.c (according to the janitorial page) so I might start there (hoping not all of them are so tricky ;) )
Thanks for suggestions on this,
Joris
-- James Hawkins
James Hawkins wrote:
However, I don't know how to make simple tests.. as I'd really need to test wether the code I write works, and works properly :p
The best way to test the functionality of a certain api function against windows is to read the msdn docs on that function. There are certain easy things to check like the error codes that are either returned or set using SetLastError (and are read using GetLastError.) The docs will also tell you pretty precisely what the function should and should not do, and you write the tests to make sure that the functions do what they're supposed to do. A lot of the times, msdn docs will have example code and will usually show the expected output (when necessary.) You can test against this output to see if the results are the same. Some api's cant really be tested with wine's testing system because the effects may be visual etc, so the way to test that is to run the program and see if the visual change coincides with the way the program runs in windows. If you dont have a windows install to run the program from, I'm sure that someone on wine-devel can run the program for you.
That wasn't really my question; I'd want to do W->A cleanup work; but I never did so before; I am not used to work on a big project; So I better know what I'm doing before breaking code instead of fixing it; So -- is there a unit testing or so or do all people just make a bunch of extra files to make the function calls and make what they need compile? If I change, say , dlls/winmm/mci.c: winmm: mciSendStringW , how will I be able to verify the change didn't change the behavior of the function? (rather than just trusting I am sort-of sure my hacks are working??) (So I'm talking about developers testing functions, not really about tests to run for windows or so) So, how do you handle that? thanks, Joris
So -- is there a unit testing or so or do all people just make a bunch of extra files to make the function calls and make what they need compile? If I change, say , dlls/winmm/mci.c: winmm: mciSendStringW , how will I be able to verify the change didn't change the behavior of the function? (rather than just trusting I am sort-of sure my hacks are working??)
(So I'm talking about developers testing functions, not really about tests to run for windows or so) So, how do you handle that?
Yes, there is a test suite but unfortunately it's not comprehensive. I wouldn't pay too much attention to MSDN, while it's a great source of information it's also sometimes wrong. The only real way to be sure is to test the code itself. If you're just generally looking for things to do, W->A cleanup isn't the only task. You could help extend the test suite :) thanks -mike
Mike Hearn wrote:
If you're just generally looking for things to do, W->A cleanup isn't the only task. You could help extend the test suite :)
Or another possibility... since there is no longer a ~/.wine/config file installed, we really, really need some serious work on winecfg. That should be a fairly easy and self contained way to get into Wine.
Duane Clark wrote:
Mike Hearn wrote:
If you're just generally looking for things to do, W->A cleanup isn't the only task. You could help extend the test suite :)
Or another possibility... since there is no longer a ~/.wine/config file installed, we really, really need some serious work on winecfg. That should be a fairly easy and self contained way to get into Wine.
Fine by me ;) where do I start then.. I can't find much on the winehq site about that (I found a http://sourceforge.net/projects/winecfg/ but it seems the last update was over a year ago..) What's there to do, how to... etc - kind find much documentation except for the fact it's mentioned as a Todo thing :-/ Thanks for your suggestion, Joris
On Fri, Sep 10, 2004 at 08:19:09PM +0200, Joris Huizer wrote:
site about that (I found a http://sourceforge.net/projects/winecfg/ but it seems the last update was over a year ago..) What's there to do, how to... etc - kind find much documentation except for the fact it's mentioned as a Todo thing :-/
If you want to work on winecfg, use the one in the Wine tree, in the programs/winecfg directory. -- Dimi.
Joris Huizer wrote:
Fine by me ;) where do I start then.. I can't find much on the winehq site about that (I found a http://sourceforge.net/projects/winecfg/ but it seems the last update was over a year ago..) What's there to do, how to... etc - kind find much documentation except for the fact it's mentioned as a Todo thing :-/
It appears that Mike has been doing a lot of work on this. http://www.winehq.org/hypermail/wine-devel/2004/09/0221.html So you probably first want to coordinate with him. I would start by running "winecfg", and seeing what doesn't work, which is a lot. For example, on the very first tab, you can select a "Windows Version", but changing the setting doesn't actually change anything (it should make/alter a registry entry). The winecfg code is in wine/programs/winecfg. A long discussion of things that are needed is in the thread starting: http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html In fact, you probably want to go to: http://www.winehq.org/hypermail/wine-devel/2004/08/index.html http://www.winehq.org/hypermail/wine-devel/2004/09/index.html And then search for all subjects containing winecfg. By the way, I really do like the look mentioned here: http://www.winehq.org/hypermail/wine-devel/2004/09/0220.html It is much improved over the current look. Hopefully that will become part of winecfg.
Saturday, September 11, 2004 8:34 AM Duane Clark
By the way, I really do like the look mentioned here: http://www.winehq.org/hypermail/wine-devel/2004/09/0220.html It is much improved over the current look. Hopefully that will become part of winecfg.
Per suggestion of Robert Shearman, I removed the 'Settings' frame which gives the other two frames more 'breathing' room and simplifies the appearance. Mike, I haven't done anything more on this as I figured you have your own ideas but if you like the look, I'll be happy to post a diff (English resource only at this time) for inclusion with your own work. Again, these are cosmetic changes only, nothing functional and only to the app tab. Thanks, Roger
So -- is there a unit testing or so or do all people just make a bunch of extra files to make the function calls and make what they need compile? If I change, say , dlls/winmm/mci.c: winmm: mciSendStringW , how will I be able to verify the change didn't change the behavior of the function? (rather than just trusting I am sort-of sure my hacks are working??) as a side note, changing the W->A calls for mciSendStringW only makes sense when the MCI drivers (at least the 32 bit ones) are ported to unicode interface (which another magnitude of effort than just the mciSendStringW function). A+
participants (7)
-
Dimitrie O. Paun -
Duane Clark -
Eric Pouech -
James Hawkins -
Joris Huizer -
Mike Hearn -
Roger Olson