Wine Traffic #113 For 13 Jan 2002

The attached revision to Alexandres patch modifies the Wine makefiles such that a Linux developer can:

make test (to confirm all regression tests)
make clean-test (to clear the tests and try again)

It also creates three sample tests in programs/winetest/samples which hopefully demonstrate to a test author how to write a test. (The *.test files are human readable).

It has provisions for Perl and Winelib/C tests, as well as allowing for the arbitrary execution of any other command (which should allow any other test tools to be plugged in).

It has many flaws, but is intended as a possible jumpstart to get this process rolling.

Flaws:

1. It has no provision for use on Windows. IMO the right way to fix this is to go through the effort of making Wine's ./configure script be intelligent enough to build 'Winelib' programs, so that in Windows a 'make test' should just work.
2. I really don't like that a C/Winelib test requires its own directory (see samples/sample3). However, AFAICT, that was the only way to create a simple and clean build environment for the Winelib app.
3. No doco.

Thoughts? Comments?

Finally, the more I think about my structure of using the '.test' files, the more I believe it is the right solution, because I think it gives us great long term flexibility.

For example, say we have 70 Winelib/C tests that are big and bloated and we want to fix that. We could define a new make target, say a '.test.so'. We could modify winetest to be able to load a .test.so file and call main() with the right parameters and suddenly all of our bloat is gone. We'd just need a rule to build a .test.so file from a .test.c file, and then we'd need to tweak our foo.test file to add a new command 'so_test=foo.test.so' instead of 'invoke=foo' and we're done. We could probably even eliminate the .spec file (only for console apps, obviously).

I think the bottom line question is whether or not the test scripts should be built such that we depend on a shell script (runtest) and a configuration file for each test (foo.test), or whether we rely completely on the Makefiles to hold the test configuration information.

I think either choice is valid, but let me lay down the gauntlet: replace my 'winetest/samples' directory with a Make based equivalent that allows for the same sorts of tests, and makes it similarly obvious to a newcomer how to add a new test. You are better with Make than I am; you may persuade me readily with a patch.

Just replace this:

TESTS = sample1.test sample2.test sample3.test

in your makefile by:

PLTESTS = sample2.pl
CTESTS = sample3.c

and delete the .test files (there is no SHTESTS for shell tests, but I think that's a feature if we want portability).

Creating a new test involves simply adding its name on the right line; no .test to write, no .spec file, no new Makefile.

(if you'd like to try it I have committed the rules for PLTESTS so this should work now; CTESTS will still need a bit more work)

My attempt to convince you otherwise:

http://oss.software.ibm.com/developer/opensource/linux http://www.ibm.com/linux

Paul Clarke, IBM

Many people at IBM know about Wine; in fact a lot of developers there depend on it everyday (IBM is standardized on Notes for messaging...).

Many non developers also know about it, if for no other reason that I've been a pest.<grin>

One senior manager at IBM explained it to me as follows: Most senior management at IBM has been with the company for a long time. Most of those went through the OS/2 era. Many people may not realize it, but IBM put their heart and soul into OS/2 - and were burned very, very badly by it. As a consequence, many people at IBM are understandably very reluctant to contemplate another attack on Windows dominance of the desktop.

This doesn't mean that I think helping Wine would be bad for IBM (or I wouldn't have been such a pest), but it may help folks to understand why IBM isn't very focused on Linux as a desktop OS.

OS/2 ran Windows apps, and from about version 2 upwards ran all DOS and Windows stuff perfectly (except for the Win32s stuff). I am sure IBM does not want to make the same mistake again.

However WinOS/2 actually was running Windows 3.x. In fact, the technology was extremely similar to SCO Merge (which now has offspring-- Win4Lin). One nice thing it could do that win4lin could not was actually put toplevel windows onto the desktop directly (though they still had the win31 look). This would look similar to running Wine in non-desktop and non-managed mode, although the windows actually were managed by OS/2.

Some people would argue that had IBM comitted to supporting Win32 stuff that OS/2 would still be around. Of course the bottom line is that the way they were doing this meant MS got the money for a copy of Windows every time someone bought OS/2. Not good. Wine wouldn't have that problem assuming it would be using all wine DLLs.

As for IBM investing in Wine. I suppose there are a couple things they could do. For one, they could somehow use the $10e6 you suggest but who would they pay it to. What might be more helpful is if some of the guys and gals that wrote OS/2 would help out with Wine. They would probably be extremely familiar with Win32 seeing as how OS/2 was originally a joint MS/IBM project which MS got out of when they hacked Win3.0 to support virtual memory on a 386 and decided to make NT. Now while the NT kernel was developed by former VMS guys and gals from DEC, some of Win32 resembles OS/2 because some of those developers went on to work on NT. Which by the way no-one has confirmed that MS ever said it actually stood for New Technology.. more likely it stands for Nice Tits, but that's another story.

Anyway, the bottom line is that IBM is not going to start throwing money at stuff. They made that mistake with OS/2 and look where that got 'em. No, IBM spends money when and where it helps their bottom line. Taking down MS does not help their bottom line. Building their own services does help their bottom line. IBM could care less if everyone could run Windows software on Linux. They are in the business of providing the totally integrated system. Running 3rd party stuff is usually not a top priority.

Note that IBM has already caught the eye of MS with IBMs ad campaign for moving onto 390 systems running Linux. Some of those internal MS memos recently released are really anti-IBM. Right now I think MS is at the point where they have competitors. They can go after companies using Linux just like they have gone after companies in the past. They are also going after various IT admins who use Linux for certain tasks suggesting that MS software is better for everything. Of course anybody that tells you that one system is better than all others is full of shit, but hey, it sounds good to some managers who don't want to listen to the people they have working for them. Let 'em waste their money on MS. When it breaks, let 'em waste more money on moving it back to what worked. MS is going to shoot itself in the foot soon enough, no need to bring out your own shotgun.

This patch changes the NLS currency of all Euro countries to use the "EUR" as international currency and the euro-sign (iso-8859-15, character 164).

I am a bit unsure if we can just specify the character that way, but it should work.

Hmm. While I'm do not doubt that some users of Wine might find this useful, Wine is supposed to do what Windows does and if Windows does something wrong Wine usually should as well.

If I'm not mistaken the .nls contains that default values. It is entirely possible to change the currency and such in the registry to specify things differently for each user.

That said I would find it unlikely that this patch would cause any serious problem. After all, as I said, the user can specify whatever currency it likes after the defaults have been set and every application is supposed to be able to handle it.

So I do not really oppose the patch. It is more the principle I'm intrested in: Under what circumstances should Wine change the behavior if Windows does something in the wrong way?

this is an RFC document describing an API that may be used to provide Windows NT Style "NamedPipe" functionality. it will be of interest to samba, wine, freedce and win32 developers wishing to port applications to unix (via the wine win32 implementation of NamedPipes).

the functionality described in this document is equivalent to, if you have access to the MSDN, the following (incomplete list of) Win32 functions:

• CreateNamedPipe (returns a file handle)
• TransactNamedPipe
• a read operation on the named pipe file handle, above
• a write operation on the named pipe file handle, above
• a close operation on the named pipe file handle, above
• WaitNamedPipe

there follows a list of function declarations.

these are samba-specific functions that are only of use to SAMBA 3 developers.

int named_pipe_create(


connection_struct *connection, /* contains all info needed, e.g. user security context */
const char *pipe_name, /* e.g. \\server\PIPE\pipe_name or \\.\PIPE\pipe_name */

);

this function returns -1 on failure or an SMB file index (fnum) on success.

it is called when an SMBopenX or NTcreateX is received.

from memory, the access point is api_pipe_open(), in pipe.c or reply.c.

STATUS named_pipe_transact(connection_struct *connection,


int fnum, /* the SMB file index from the named_pipe_create */
const char *transact_data_to_send, /* smb data received, to send to NamedPipe service */
int transact_data_length, /* zero or more bytes */
char *transact_receive_buffer, /* NamedPipe data received, to be sent over SMB */
int *transact_receive_length); /* zero or more bytes */

this function returns an NT status code.

if there is more data to be received, then the function must return ERROR_MORE_DATA. NT_STATUS_OK is returned on success.

from memory, the access point is api_pipe_readwrite() or reply_trans2(), or maybe reply_pipe_trans(). i don't recall which. again, it'll be in pipe.c or reply.c.

STATUS named_pipe_read(connection_struct *connection,


int fnum, /* the SMB file index from the named_pipe_create */
char *transact_receive_buffer, /* NamedPipe data received, to be sent over SMB */
int *transact_receive_length); /* zero or more bytes */

this function returns an NT status code.

NT_STATUS_OK is returned on success.

this one's to be called by pipe_read() (api_pipe_read()?)

STATUS named_pipe_write(connection_struct *connection,


int fnum, /* the SMB file index from the named_pipe_create */
const char *transact_data_to_send, /* smb data received, to send to NamedPipe service */
int transact_data_length); /* zero or more bytes */


this function returns an NT status code.

NT_STATUS_OK is returned on success.

this one's to be called by pipe_write() (api_pipe_write()?)

the use of this API is quite simple, and provides a clean "cut-off" point between samba and all NamedPipe transactions.

the transport that SMB implements is called "Named Pipes". look up the MSDN starting with CreateNamedPipe.

Named Pipes are basically the following features:

• the caller's user security context may be transferred to the server application, for the server application to use as it sees fit
• guaranteed, ordered transaction-based message passing, where the maximum message size is negotiable.

basically, it's an incredibly powerful system, and unix has ***nothing*** remotely resembling it.

unix doesn't even support the concept of a remote user in order for a remote user to be relevant over a named pipe, for pity's sake!

unix supports TCP (guaranteed and ordered data delivery) and it supports UDP (guaranteed message sizes) but it doesn't support both.

and NT "Named Pipes" do.

which is why microsoft decided to use them as a transport for dce/rpc.

and it's worthwhile pointing this out again: that's the *only* relationship between named pipes and dce/rpc.

one uses the other.

there _is_ no special MSRPC-namedpipe-interdependent- transport-thing.

in other words, it is possible to implement NamedPipes in SAMBA-3, knowing absolutely _nothing_ about dce/rpc _whatsoever_, and then to give the API functions to a dce/rpc developer and say, "write a transport plugin module for your dce/rpc runtime environment that uses _this_ api", and they can.

but - and i'll say it again - without that "Named Pipe" API in SAMBA-3, there's absolutely _no_ point in any further discussion, as no progress can be made.

Is anybody working on support for playing ADPCM wave files under Wine? If not, I'd like to take a crack at it.

I have an app that I use (Delorme's AAA MapNGo 4.0) that uses ADPCM wave files to contain spoken information on attractions. I know that Wine can access my sound system to play normal PCM wave files, as MN4 also has speech synthesis that does work. However, any attempt to play a ADPCM file results in the program pausing for a length of time, then continuing. I infer that this is because the lower levels of Wine don't know how to handle ADPCM.

ADPCM isn't rocket science - several programs, including sox, understand the protocol.

So, is anybody working on this (outside of TG and Lindows)? Any (non-null) pointers to useful information on how Wine has put together the sound subsystem? I'm not a Windows programmer, I'm an embedded systems and DSP person, but if I can find a block of code to hook into I can make this happen.

well, to make things a bit harder, (at least) two ADPCM exist:
- IMA and MS
basic algorithm are quite the same, coeff tables differ a bit.

I did start a while ago an IMA ADPCM driver for wine it's not finished yet (basically, didn't find time to look at in depth docs for some details, like coding/decoding of stereo vs mono) it's far from being finished and tested, but the framework (wine integration, driver infrastructure) is in place, there's just some need to concentrate on codec code

so, if you're ready to go for it, I can send you the code and give you the directions to end up the job

OK. To break at function foo of dll E:\somepath\MyDll.DLL

break MYDLL.DLL.foo

I'll update the file.

NOW the real question.

I am chasing a bug which makes no sense. I want to single-step through the DLL's DllMain but since it isn't exported the debugger can't get its address (I presume) so I can't set it as a break point. Is there a way to figure out what it's address is?