W->A calls

[Joris Huizer]

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]

> 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  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

[Joris Huizer]

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

[Mike Hearn]

> 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

[Duane Clark]

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.

winecfg (was Re: W->A calls)

[Joris Huizer]

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

winecfg (was Re: W->A calls)

[Dimitrie O. Paun]

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.

winecfg (was Re: W->A calls)

[Duane Clark]

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.

winecfg (was Re: W->A calls)

[Roger Olson]

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

[Eric Pouech]

> 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+