January 2003 - Wine-Devel - list.winehq.org

Re: WIP RPC test code (RFC): rpc_K01-pre2.diff

by Eric Pouech

> o Failure in the child process doesn't cause failure of > the test (is there someone else who has this solved > for their test whose code I can borrow?) couldn't you test the output of GetExitProcess (and ensure that when a test fails, we somehow return an error code) ? > o rpcss.exe.so runs from the INSTALLED wine, not from > the build tree!! This is totally unacceptable, but > I'm not sure what would be a wise way to solve the > problem. I need to change the way rpcss gets invoked > by rpcrt4.dll. The best I can think of so far, would > be to provide some global override (via a function > call, I guess) for where rpcss.exe.so should be found, > and then use this "feature" to ensure that during testing, > rpcss.exe.so is invoked from the build tree instead of > from the PATH environment variable. Any thoughts on this? what about an environment variable ? we already use something like this for the wineserver (WINESERVER), the wine console (WINECONSOLE)... why not rpcss (WINERPCSS) ? > o There's a way to tell midl to deal with these namespace > issues automagically so that the same .exe can be it's > own client and server without a namespace conflict.... > anyone know of such a feature? there isn't is ATM however, MS' midl has a /prefix option that does just what you need sounds like the way to go (another solution would be to put either client or server in a DLL (in fact a wine builtin DLL) so that you separate the name space between to two A+ -- Eric Pouech

Jan. 4, 2003

Re: interesting crash in msvc6.0 setup

by Greg Turner

On Saturday 04 January 2003 02:42 pm, Dan Kegel wrote: > :Repeat > > del "E:\vs60wiz.exe" > if exist "E:\vs60wiz.exe" goto Repeat > del "C:\WINDOWS\DEL4056.BAT" It's probably relying on the file being locked. I wonder, is it "niced" in Windows? Lame. -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Jan. 4, 2003

WIP RPC test code (RFC): rpc_K01-pre2.diff

by Greg Turner

OK, this is my a preliminary cut at what an RPC test might look like. It also fixes a couple of wine bugs/missing functionalities that I noticed along the way. Several problems with this patch exist, all of them somewhat trivial. I'll divide these into categories for your amusement: PROBLEMS I HOPE TO SOLVE BEFORE SUBMITTING THIS PATCH o Failure in the child process doesn't cause failure of the test (is there someone else who has this solved for their test whose code I can borrow?) o rpcss.exe.so runs from the INSTALLED wine, not from the build tree!! This is totally unacceptable, but I'm not sure what would be a wise way to solve the problem. I need to change the way rpcss gets invoked by rpcrt4.dll. The best I can think of so far, would be to provide some global override (via a function call, I guess) for where rpcss.exe.so should be found, and then use this "feature" to ensure that during testing, rpcss.exe.so is invoked from the build tree instead of from the PATH environment variable. Any thoughts on this? o Doesn't actually do much real testing yet (this is just because I haven't finished the code yet, no problem here at all, really). PROBLEMS THAT IM WILLING TO TOLERATE FOR THE MOMENT o Had to comment out the exception handling code in the generated _c and _s files. o Some warnings are generated unless a few trivial things get changed in the generated _c and _s files. o Had to make every unit compiled into my test into a separate test (any way to turn this off for some units? For now I just added the func_filename function that testlist.c is looking for). These are marked as /* appease testlist.c */ below. AN UNCLASSIFIABLE PROBLEM Finally, there is the issue that I had to rename the stub functions in stringinput_c. This is pretty damn awful, because unlike the other issues, it doesn't stem from functionality that is missing in wine, so "fixing" wine still doesn't solve it. I don't know if its solvable or not. The problem stems from the fact that the entire test suite for rpcrt4 compiles into a single .exe.so file. Unless there is some way to override this arrangement, that same .exe.so must be both the client and the server. This is why I have stub_ShutdownServer, for example, instead of ShutdownServer (which is already defined to be the manager routine!) One of the following would allow me to solve this elegantly: o There's an acceptable way for me to tell the autocrap to generate multiple .exe.so's per dll test... is there? o There's a way to tell midl to deal with these namespace issues automagically so that the same .exe can be it's own client and server without a namespace conflict.... anyone know of such a feature? o Some other solution exists that I haven't thought of... note that the fixme, below: +/* StringInput "manager" routines (server-side implementations) + * FIXME: I had to prefix manager_ to these because otherwise + * we somehow ended up in NTDLL.sqrt!!! WTH?? + */ is incorrect (its a remnant of an attempt to solve this the converse way, renaming stuff in stringinput_s instead of stringinput_c.), and should be ignored. Blech. HOPEFULLY NOT A PROBLEM It also would be nice if some kind soul who knows the testing build incantations could run this new test under real windows and let me know if it actually works there. Thanks for your input. Here's the patch (X11): -- diff -ur -x CVS -x 'bigdif*' -x autom4te.cache ../wine.test/dlls/rpcrt4/ndr_midl.c ./dlls/rpcrt4/ndr_midl.c --- ../wine.test/dlls/rpcrt4/ndr_midl.c 2002-12-05 15:05:46.000000000 -0600 +++ ./dlls/rpcrt4/ndr_midl.c 2003-01-03 21:25:50.000000000 -0600 @@ -214,6 +214,7 @@ pStubMsg->RpcMsg = pRpcMsg; pStubMsg->Buffer = pRpcMsg->Buffer; pStubMsg->BufferLength = pRpcMsg->BufferLength; + pStubMsg->BufferEnd = pStubMsg->Buffer + pStubMsg->BufferLength; /* FIXME: determine the proper return value */ return NULL; @@ -236,8 +237,9 @@ return NULL; stubmsg->BufferLength = stubmsg->RpcMsg->BufferLength; - stubmsg->BufferEnd = stubmsg->BufferStart = 0; - return (stubmsg->Buffer = (unsigned char *)stubmsg->RpcMsg->Buffer); + stubmsg->Buffer = stubmsg->BufferStart = (unsigned char *)stubmsg->RpcMsg->Buffer; + stubmsg->BufferEnd = stubmsg->Buffer + stubmsg->BufferLength; + return (stubmsg->Buffer); } /*********************************************************************** * NdrFreeBuffer [RPCRT4.@] @@ -247,7 +249,7 @@ TRACE("(pStubMsg == ^%p): wild guess.\n", pStubMsg); I_RpcFreeBuffer(pStubMsg->RpcMsg); pStubMsg->BufferLength = 0; - pStubMsg->Buffer = (unsigned char *)(pStubMsg->RpcMsg->Buffer = NULL); + pStubMsg->Buffer = pStubMsg->BufferEnd = (unsigned char *)(pStubMsg->RpcMsg->Buffer = NULL); } /************************************************************************ diff -ur -x CVS -x 'bigdif*' -x autom4te.cache ../wine.test/dlls/rpcrt4/tests/Makefile.in ./dlls/rpcrt4/tests/Makefile.in --- ../wine.test/dlls/rpcrt4/tests/Makefile.in 2002-10-07 16:54:07.000000000 -0500 +++ ./dlls/rpcrt4/tests/Makefile.in 2003-01-03 21:25:50.000000000 -0600 @@ -6,7 +6,9 @@ IMPORTS = rpcrt4 CTESTS = \ - rpc.c + rpc.c \ + stringinput_c.c \ + stringinput_s.c @MAKE_TEST_RULES@ diff -ur -x CVS -x 'bigdif*' -x autom4te.cache ../wine.test/dlls/rpcrt4/tests/rpc.c ./dlls/rpcrt4/tests/rpc.c --- ../wine.test/dlls/rpcrt4/tests/rpc.c 2002-12-23 19:09:52.000000000 -0600 +++ ./dlls/rpcrt4/tests/rpc.c 2003-01-03 21:25:51.000000000 -0600 @@ -22,10 +22,39 @@ #include <winbase.h> #include <winnt.h> #include <winerror.h> +#include <stdio.h> #include "wine/unicode.h" #include "rpc.h" +#include "stringinput.h" +#include "stringinput_midl.h" + +static char base[MAX_PATH]; +static char selfname[MAX_PATH]; + +static int myARGC; +static char** myARGV; + +/****************************************************************** + * init + * + * generates basic information like: + * base: absolute path to curr dir + * selfname: the way to reinvoke ourselves + */ +static int init(void) +{ + myARGC = winetest_get_mainargs( &myARGV ); + if (!GetCurrentDirectoryA(sizeof(base), base)) return 0; + strcpy(selfname, myARGV[0]); + return 1; +} + +/*************************************************************** + * UUID Tests + */ + static UUID Uuid_Table[10] = { { 0x00000000, 0x0000, 0x0000, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00} }, /* 0 (null) */ { 0xdeadbeef, 0xdead, 0xbeef, {0x10, 0x21, 0x35, 0x56, 0x89, 0xa0, 0xf4, 0x8a} }, /* 1 */ @@ -119,8 +148,219 @@ } } +/************************************************************* + * StringInput tests + */ + +/* here we define all the protocol sequences RPC currently works with. */ +#define SPSCount 1 +static char *SupportedProtocolSequences[SPSCount] = { + "ncalrpc" +}; + +#define RCCount 10 +static char *RandomCruds[RCCount] = { + "This is just some random crud", + "Designed \r\n to \r\n test \n", + "098172365 the RPC capabilities", + "!#$^*@%$*()*)", + "of this thing.\n", + "x", + "blabalbablab ablab abla", + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG" + "<><><><><,.,.____&&&&&&_+-=_+-=_+jjjjjjj,.,.,><><><>,.,.<><????????abcdefghijklmnopqrstuvwxyzABCDEFG", + "", + "\001\002\003\004\005\006\007\008\009\010\011\012\013\014\015\016" + "\017\018\019\020\021\022\023\024\025\026\027\028\029\030\031\032" + "\033\034\035\036\037\038\039\040\041\042\043\044\045\046\047\048" + "\049\050\051\052\053\054\055\056\057\058\059\060\061\062\063\064" + "\065\066\067\068\069\070\071\072\073\074\075\076\077\078\079\080" + "\081\082\083\084\085\086\087\088\089\090\091\092\093\094\095\096" + "\097\098\099\100\101\102\103\104\105\106\107\108\109\110\111\112" + "\113\114\115\116\117\118\119\120\121\122\123\124\125\126\127\128" + "\129\130\131\132\133\134\135\136\137\138\139\140\141\142\143\144" + "\145\146\147\148\149\150\151\152\153\154\155\156\157\158\159\160" + "\161\162\163\164\165\166\167\168\169\170\171\172\173\174\175\176" + "\177\178\179\180\181\182\183\184\185\186\187\188\189\190\191\192" + "\193\194\195\196\197\198\199\200\201\202\203\204\205\206\207\208" + "\209\210\211\212\213\214\215\216\217\218\219\220\221\222\223\224" + "\225\226\227\228\229\230\231\232\233\234\235\236\237\238\239\240" + "\241\242\243\244\245\246\247\248\249\250\251\252\253\254\255" +}; + +unsigned int sRCIndex; + +void *__RPC_USER MIDL_user_allocate(size_t size) +{ + trace ( "Wow, __MIDL_user_allocate was called.\n" ); + return malloc(size); +} + +void __RPC_USER MIDL_user_free(void *ptr) +{ + trace ( "Wow, __MIDL_user_free was called.\n" ); + free(ptr); +} + +/* this test implements the server side of the stringinput rpc server; + * it spawns the client side as a separate process (same exe). + */ +void StringInputViaRPC() +{ + unsigned int MaxCalls = 50; + unsigned int PSIndex; + UINT32 status; + unsigned char *pszProtocolSequence; + RPC_BINDING_VECTOR *pbvBindings; + char buffer[MAX_PATH]; + PROCESS_INFORMATION info; + STARTUPINFOA si; + + for (PSIndex = 0; PSIndex < SPSCount; PSIndex++) { + pszProtocolSequence = SupportedProtocolSequences[PSIndex]; + + /* ready the stringinput server */ + status = RpcServerUseProtseq(pszProtocolSequence, MaxCalls ,0); + ok( (!status), "RpcServerUseProtseq failed with 0x%x.\n", status ); + + status = RpcServerInqBindings(&pbvBindings); + ok( (!status), "RpcServerInqBindings failed with 0x%x.\n", status ); + + status = RpcEpRegister(stringinput_v1_0_s_ifspec, pbvBindings, 0, 0); + ok( (!status), "RpcEpRegister failed with 0x%x\n.", status ); + + status = RpcServerRegisterIf(stringinput_v1_0_s_ifspec, 0, 0); + ok( (!status), "RpcServerRegisterIf failed with 0x%x\n.", status ); + + /* spawn the stringinput client process (ourselves, with different arguments) */ + memset(&si, 0, sizeof(si)); + si.cb = sizeof(si); + + sprintf(buffer, "%s tests/rpc.c stringinput %s", selfname, pszProtocolSequence); + ok(CreateProcessA(NULL, buffer, NULL, NULL, TRUE, 0L, NULL, NULL, &si, &info), "CreateProcess (%s)", buffer); + + /* init the expected server inputs */ + sRCIndex = 0; + + /* start stringinput services. termination should occur due to a call from the client */ + status = RpcServerListen(1, MaxCalls, 0); + ok( (!status), "RpcServerListen failed with 0x%x\n.", status ); + + /* make sure the client process shut down */ + ok(WaitForSingleObject(info.hProcess, 5000) == WAIT_OBJECT_0, "Child process termination (%s)", buffer); + CloseHandle(info.hProcess); + CloseHandle(info.hThread); + + /* shut down stringinput server */ + status = RpcServerUnregisterIf(stringinput_v1_0_s_ifspec, 0, 0); + ok( (!status), "RpcServerUnregisterIf failed with 0x%x\n", status); + + status = RpcEpUnregister(stringinput_v1_0_s_ifspec, pbvBindings, 0); + ok( (!status), "RpcEpUnregister failed with 0x%x\n", status); + + status = RpcBindingVectorFree(&pbvBindings); + ok( (!status), "RpcBindingVectorFree failed with 0x%x\n", status); + } +} + +/* these forward definitions provide a (horribly) kludgy way to get at the stubs + * instead of the manager routines (normally they don't reside in the + * same process so it's a nonissue). FIXME: find a better solution. + */ + +extern void stub_StringReceive(unsigned char *); +extern void stub_ShutdownServer(void); + +void doStringInputClient(char *pszProtocolSequence) +{ + UINT32 status; + LPSTR pszStringBinding; + char *theMessage; + unsigned int cRCIndex; + + trace( "String Input Client is running with PS %s.\n", pszProtocolSequence ); + + /* prepare ourselves to be the client */ + status = RpcStringBindingComposeA(0, pszProtocolSequence, NULL, NULL, 0, &pszStringBinding); + ok( (!status), "RpcStringBindingCompose failed with 0x%x\n", status); + + status = RpcBindingFromStringBindingA(pszStringBinding, &stringinput_binding_handle); + + ok( (!status), "RpcBindingFromStringBinding failed with 0x%x\n", status); + + status = RpcStringFreeA((unsigned char**)&pszStringBinding); + ok( (!status), "RpcStringFree failed with 0x%x\n", status); + + cRCIndex = 0; + theMessage = RandomCruds[cRCIndex]; + + stub_StringReceive("FIXME"); + + stub_ShutdownServer(); + + status = RpcBindingFree(&stringinput_binding_handle); + ok( (!status), "RpcBindingFree failed with 0x%x\n", status); +} + +/* StringInput "manager" routines (server-side implementations) + * FIXME: I had to prefix manager_ to these because otherwise + * we somehow ended up in NTDLL.sqrt!!! WTH?? + */ +void StringReceive(unsigned char *msg) +{ + /* FIXME */ +} + +void ShutdownServer() +{ + UINT32 status; + trace( "Shutdown request received.\n" ); + status = RpcMgmtStopServerListening(0); + ok( (!status), "RpcMgmtStopServerListening failed with 0x%x\n", status); +} + START_TEST( rpc ) { + int b = init(); + ok(b, "Basic init of RPC test"); + if (!b) return; + + if ((myARGC >= 4) && (!strcmp(myARGV[2], "stringinput"))) { + doStringInputClient(myARGV[3]); + return; + } + trace ( " ** Uuid Conversion and Comparison Tests **\n" ); UuidConversionAndComparison(); + trace ( " ** StringInput via RPC Tests **\n" ); + StringInputViaRPC(); } diff -ur -x CVS -x 'bigdif*' -x autom4te.cache ../wine.test/include/rpcndr.h ./include/rpcndr.h --- ../wine.test/include/rpcndr.h 2002-12-02 23:52:12.000000000 -0600 +++ ./include/rpcndr.h 2003-01-03 21:25:51.000000000 -0600 @@ -95,6 +95,10 @@ #define __RPC_CALLEE WINAPI #define RPC_VAR_ENTRY WINAPIV +#define NdrFcShort(s) (unsigned char)(s & 0xff), (unsigned char)(s >> 8) +#define NdrFcLong(s) (unsigned char)(s & 0xff), (unsigned char)((s & 0x0000ff00) >> 8), \ + (unsigned char)((s & 0x00ff0000) >> 16), (unsigned char)(s >> 24) + typedef struct { void *pad[2]; --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./dlls/rpcrt4/tests/stringinput.acf 2003-01-04 15:10:55.000000000 -0600 @@ -0,0 +1,4 @@ +[ implicit_handle(handle_t stringinput_binding_handle) ] +interface stringinput +{ +} --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./dlls/rpcrt4/tests/stringinput.h 2003-01-03 21:25:51.000000000 -0600 @@ -0,0 +1,24 @@ +/*** Autogenerated by WIDL 0.1 from stringinput.idl - Do not edit ***/ +#include "rpc.h" +#include "rpcndr.h" + +#ifndef __WIDL_STRINGINPUT_H +#define __WIDL_STRINGINPUT_H +#ifdef __cplusplus +extern "C" { +#endif +/***************************************************************************** + * stringinput interface (v1.0) + */ +DEFINE_GUID(IID_stringinput, 0xcdf93a7e, 0x2622, 0x4ede, 0x99,0xb3, 0xaa,0x4a,0x0d,0xac,0x86,0x15); +extern RPC_IF_HANDLE stringinput_v1_0_c_ifspec; +extern RPC_IF_HANDLE stringinput_v1_0_s_ifspec; +void StringReceive( + unsigned char* thestring); +void ShutdownServer( + ); + +#ifdef __cplusplus +} +#endif +#endif /* __WIDL_STRINGINPUT_H */ --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./dlls/rpcrt4/tests/stringinput.idl 2003-01-04 15:11:12.000000000 -0600 @@ -0,0 +1,15 @@ +/* + * this defines a super-simple RPC service which passes a + * single string to the server and returns nothing. + */ + +[ + uuid(cdf93a7e-2622-4ede-99b3-aa4a0dac8615), + version(1.0) +] + +interface stringinput +{ +void StringReceive([in, string, ref] unsigned char *thestring); +void ShutdownServer(void); +} --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./dlls/rpcrt4/tests/stringinput_c.c 2003-01-04 15:03:00.000000000 -0600 @@ -0,0 +1,228 @@ +/* Generated from MIDL for now. + * Exception hanlding code was removed and other touch-ups applied. + * Eventually, widl will generate this file + */ + +#include <assert.h> + +#include <string.h> +#if defined( _ALPHA_ ) +#include <stdarg.h> +#endif + +#include "stringinput.h" +#include "stringinput_midl.h" + +#define TYPE_FORMAT_STRING_SIZE 7 +#define PROC_FORMAT_STRING_SIZE 9 + +typedef struct _MIDL_TYPE_FORMAT_STRING + { + short Pad; + unsigned char Format[ TYPE_FORMAT_STRING_SIZE ]; + } MIDL_TYPE_FORMAT_STRING; + +typedef struct _MIDL_PROC_FORMAT_STRING + { + short Pad; + unsigned char Format[ PROC_FORMAT_STRING_SIZE ]; + } MIDL_PROC_FORMAT_STRING; + + +extern const MIDL_TYPE_FORMAT_STRING __MIDL_TypeFormatString; +extern const MIDL_PROC_FORMAT_STRING __MIDL_ProcFormatString; + +/* Standard interface: stringinput, ver. 1.0, + GUID={0xcdf93a7e,0x2622,0x4ede,{0x99,0xb3,0xaa,0x4a,0x0d,0xac,0x86,0x15}} */ + +handle_t stringinput_binding_handle; + + +static const RPC_CLIENT_INTERFACE stringinput___RpcClientInterface = + { + sizeof(RPC_CLIENT_INTERFACE), + {{0xcdf93a7e,0x2622,0x4ede,{0x99,0xb3,0xaa,0x4a,0x0d,0xac,0x86,0x15}},{1,0}}, + {{0x8A885D04,0x1CEB,0x11C9,{0x9F,0xE8,0x08,0x00,0x2B,0x10,0x48,0x60}},{2,0}}, + 0, + 0, + 0, + 0, + 0, + 0 + }; +RPC_IF_HANDLE stringinput_v1_0_c_ifspec = (RPC_IF_HANDLE)& stringinput___RpcClientInterface; + +extern const MIDL_STUB_DESC stringinput_StubDesc; + +/* this next is not used so I commented it out to avoid an "unused" warning. + * Nevertheless, MIDL generates it, WTH should we do about that !? + */ +/* static RPC_BINDING_HANDLE stringinput__MIDL_AutoBindHandle; */ + +/* HACK: I prefixed the stubs with stub_ to avoid namespace conflicts!!! + * This is unacceptable if we are going to generate these, surely + * a better solution to this problem exists + * FIXME + */ + +void stub_StringReceive( + /* [ref][string][in] */ unsigned char __RPC_FAR *thestring) +{ + + RPC_BINDING_HANDLE _Handle = 0; + + RPC_MESSAGE _RpcMessage; + + MIDL_STUB_MESSAGE _StubMsg; + + if(!thestring) + { + /* RpcRaiseException(RPC_X_NULL_REF_POINTER); */ + /* unimplemented, so for now... */ + assert(FALSE); + } + /* RpcTryFinally + { */ + NdrClientInitializeNew( + ( PRPC_MESSAGE )&_RpcMessage, + ( PMIDL_STUB_MESSAGE )&_StubMsg, + ( PMIDL_STUB_DESC )&stringinput_StubDesc, + 0); + + + _Handle = stringinput_binding_handle; + + + _StubMsg.BufferLength = 12U; + NdrConformantStringBufferSize( (PMIDL_STUB_MESSAGE) &_StubMsg, + (unsigned char __RPC_FAR *)thestring, + (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[4] ); + + NdrGetBuffer( (PMIDL_STUB_MESSAGE) &_StubMsg, _StubMsg.BufferLength, _Handle ); + + NdrConformantStringMarshall( (PMIDL_STUB_MESSAGE)& _StubMsg, + (unsigned char __RPC_FAR *)thestring, + (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[4] ); + + NdrSendReceive( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char __RPC_FAR *) _StubMsg.Buffer ); + + /* } + RpcFinally + { */ + NdrFreeBuffer( (PMIDL_STUB_MESSAGE) &_StubMsg ); + + /* } + RpcEndFinally */ + +} + + +void stub_ShutdownServer( void) +{ + + RPC_BINDING_HANDLE _Handle = 0; + + RPC_MESSAGE _RpcMessage; + + MIDL_STUB_MESSAGE _StubMsg; + + /* RpcTryFinally + { */ + NdrClientInitializeNew( + ( PRPC_MESSAGE )&_RpcMessage, + ( PMIDL_STUB_MESSAGE )&_StubMsg, + ( PMIDL_STUB_DESC )&stringinput_StubDesc, + 1); + + + _Handle = stringinput_binding_handle; + + + _StubMsg.BufferLength = 0U; + NdrGetBuffer( (PMIDL_STUB_MESSAGE) &_StubMsg, _StubMsg.BufferLength, _Handle ); + + NdrSendReceive( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char __RPC_FAR *) _StubMsg.Buffer ); + + /* } + RpcFinally + { */ + NdrFreeBuffer( (PMIDL_STUB_MESSAGE) &_StubMsg ); + + /* } + RpcEndFinally */ + +} + + +static const MIDL_STUB_DESC stringinput_StubDesc = + { + (void __RPC_FAR *)& stringinput___RpcClientInterface, + MIDL_user_allocate, + MIDL_user_free, + /* MIDL does not provide these next braces. + * Without them, there is a warning due to the union. + */ + { &stringinput_binding_handle }, + 0, + 0, + 0, + 0, + __MIDL_TypeFormatString.Format, + 1, /* -error bounds_check flag */ + 0x10001, /* Ndr library version */ + 0, + 0x50100a4, /* MIDL Version 5.1.164 */ + 0, + 0, + 0, /* notify & notify_flag routine table */ + 1, /* Flags */ + 0, /* Reserved3 */ + 0, /* Reserved4 */ + 0 /* Reserved5 */ + }; + +#if !defined(__RPC_WIN32__) +#error Invalid build platform for this stub. +#endif + +static const MIDL_PROC_FORMAT_STRING __MIDL_ProcFormatString = + { + 0, + { + + 0x4d, /* FC_IN_PARAM */ +#ifndef _ALPHA_ + 0x1, /* x86, MIPS & PPC Stack size = 1 */ +#else + 0x2, /* Alpha Stack size = 2 */ +#endif +/* 2 */ NdrFcShort( 0x2 ), /* Type Offset=2 */ +/* 4 */ 0x5b, /* FC_END */ + 0x5c, /* FC_PAD */ +/* 6 */ 0x5b, /* FC_END */ + 0x5c, /* FC_PAD */ + + 0x0 + } + }; + +static const MIDL_TYPE_FORMAT_STRING __MIDL_TypeFormatString = + { + 0, + { + NdrFcShort( 0x0 ), /* 0 */ +/* 2 */ + 0x11, 0x8, /* FC_RP [simple_pointer] */ +/* 4 */ + 0x22, /* FC_C_CSTRING */ + 0x5c, /* FC_PAD */ + + 0x0 + } + }; + +/* appease testlist.c */ +void func_stringinput_c() +{ +} + --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./dlls/rpcrt4/tests/stringinput_midl.h 2003-01-03 21:25:51.000000000 -0600 @@ -0,0 +1,15 @@ +#include "rpc.h" + +#ifndef __WIDL_STRINGINPUT_MIDL_H +#define __WIDL_STRINGINPUT_MIDL_H + +/* + * These forward declarations are not provided by widl yet + */ + +extern handle_t stringinput_binding_handle; + +void* __RPC_USER MIDL_user_allocate(size_t); +void __RPC_USER MIDL_user_free( void * ); + +#endif --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./dlls/rpcrt4/tests/stringinput_s.c 2003-01-04 15:03:24.000000000 -0600 @@ -0,0 +1,229 @@ +/* Generated from MIDL for now. + * Exception hanlding code was removed and other touch-ups applied. + * Eventually, widl will generate this file + */ + +#include <assert.h> +#include <string.h> +#include "stringinput.h" +#include "stringinput_midl.h" + +#define TYPE_FORMAT_STRING_SIZE 7 +#define PROC_FORMAT_STRING_SIZE 9 + +typedef struct _MIDL_TYPE_FORMAT_STRING + { + short Pad; + unsigned char Format[ TYPE_FORMAT_STRING_SIZE ]; + } MIDL_TYPE_FORMAT_STRING; + +typedef struct _MIDL_PROC_FORMAT_STRING + { + short Pad; + unsigned char Format[ PROC_FORMAT_STRING_SIZE ]; + } MIDL_PROC_FORMAT_STRING; + +extern const MIDL_TYPE_FORMAT_STRING __MIDL_TypeFormatString; +extern const MIDL_PROC_FORMAT_STRING __MIDL_ProcFormatString; + +/* Standard interface: stringinput, ver. 1.0, + GUID={0xcdf93a7e,0x2622,0x4ede,{0x99,0xb3,0xaa,0x4a,0x0d,0xac,0x86,0x15}} */ + + +extern RPC_DISPATCH_TABLE stringinput_v1_0_DispatchTable; + +static const RPC_SERVER_INTERFACE stringinput___RpcServerInterface = + { + sizeof(RPC_SERVER_INTERFACE), + {{0xcdf93a7e,0x2622,0x4ede,{0x99,0xb3,0xaa,0x4a,0x0d,0xac,0x86,0x15}},{1,0}}, + {{0x8A885D04,0x1CEB,0x11C9,{0x9F,0xE8,0x08,0x00,0x2B,0x10,0x48,0x60}},{2,0}}, + &stringinput_v1_0_DispatchTable, + 0, + 0, + 0, + 0, + 0 + }; +RPC_IF_HANDLE stringinput_v1_0_s_ifspec = (RPC_IF_HANDLE)& stringinput___RpcServerInterface; + +extern const MIDL_STUB_DESC stringinput_StubDesc; + + +void __RPC_STUB +stringinput_StringReceive( + PRPC_MESSAGE _pRpcMessage ) +{ + MIDL_STUB_MESSAGE _StubMsg; + unsigned char __RPC_FAR *thestring; + RPC_STATUS _Status; + + ((void)(_Status)); + NdrServerInitializeNew( + _pRpcMessage, + &_StubMsg, + &stringinput_StubDesc); + + ( unsigned char __RPC_FAR * )thestring = 0; + /* RpcTryFinally + { + RpcTryExcept + { */ + if ( (_pRpcMessage->DataRepresentation & 0X0000FFFFUL) != NDR_LOCAL_DATA_REPRESENTATION ) + NdrConvert( (PMIDL_STUB_MESSAGE) &_StubMsg, (PFORMAT_STRING) &__MIDL_ProcFormatString.Format[0] ); + + NdrConformantStringUnmarshall( (PMIDL_STUB_MESSAGE) &_StubMsg, + (unsigned char __RPC_FAR * __RPC_FAR *)&thestring, + (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[4], + (unsigned char)0 ); + + if(_StubMsg.Buffer > _StubMsg.BufferEnd) + { + /* RpcRaiseException(RPC_X_BAD_STUB_DATA); */ + /* unimplemented atm so ... */ + assert(FALSE); + } + /* } + RpcExcept( RPC_BAD_STUB_DATA_EXCEPTION_FILTER ) + { + RpcRaiseException(RPC_X_BAD_STUB_DATA); + } + RpcEndExcept */ + + StringReceive(thestring); + + /* } + RpcFinally + { + } + RpcEndFinally */ + _pRpcMessage->BufferLength = + (unsigned int)((long)_StubMsg.Buffer - (long)_pRpcMessage->Buffer); + +} + +void __RPC_STUB +stringinput_ShutdownServer( + PRPC_MESSAGE _pRpcMessage ) +{ + MIDL_STUB_MESSAGE _StubMsg; + RPC_STATUS _Status; + + ((void)(_Status)); + NdrServerInitializeNew( + _pRpcMessage, + &_StubMsg, + &stringinput_StubDesc); + + /* RpcTryFinally + { + RpcTryExcept + { */ + if(_StubMsg.Buffer > _StubMsg.BufferEnd) + { + /* RpcRaiseException(RPC_X_BAD_STUB_DATA); */ + /* unimplemented ATM so ... */ + assert(FALSE); + } + /* } + RpcExcept( RPC_BAD_STUB_DATA_EXCEPTION_FILTER ) + { + RpcRaiseException(RPC_X_BAD_STUB_DATA); + } + RpcEndExcept */ + + ShutdownServer(); + + /* } + RpcFinally + { + } + RpcEndFinally */ + _pRpcMessage->BufferLength = + (unsigned int)((long)_StubMsg.Buffer - (long)_pRpcMessage->Buffer); + +} + + +static const MIDL_STUB_DESC stringinput_StubDesc = + { + (void __RPC_FAR *)& stringinput___RpcServerInterface, + MIDL_user_allocate, + MIDL_user_free, + /* These braces are not provided by MIDL. Without them, however, due to our union, + * gcc generates a warning. I HATE warnings... but what to do about this one? + */ + { 0 }, + 0, + 0, + 0, + 0, + __MIDL_TypeFormatString.Format, + 1, /* -error bounds_check flag */ + 0x10001, /* Ndr library version */ + 0, + 0x50100a4, /* MIDL Version 5.1.164 */ + 0, + 0, + 0, /* notify & notify_flag routine table */ + 1, /* Flags */ + 0, /* Reserved3 */ + 0, /* Reserved4 */ + 0 /* Reserved5 */ + }; + +static RPC_DISPATCH_FUNCTION stringinput_table[] = + { + stringinput_StringReceive, + stringinput_ShutdownServer, + 0 + }; +RPC_DISPATCH_TABLE stringinput_v1_0_DispatchTable = + { + 2, + stringinput_table + }; + +#if !defined(__RPC_WIN32__) +#error Invalid build platform for this stub. +#endif + +static const MIDL_PROC_FORMAT_STRING __MIDL_ProcFormatString = + { + 0, + { + + 0x4d, /* FC_IN_PARAM */ +#ifndef _ALPHA_ + 0x1, /* x86, MIPS & PPC Stack size = 1 */ +#else + 0x2, /* Alpha Stack size = 2 */ +#endif +/* 2 */ NdrFcShort( 0x2 ), /* Type Offset=2 */ +/* 4 */ 0x5b, /* FC_END */ + 0x5c, /* FC_PAD */ +/* 6 */ 0x5b, /* FC_END */ + 0x5c, /* FC_PAD */ + + 0x0 + } + }; + +static const MIDL_TYPE_FORMAT_STRING __MIDL_TypeFormatString = + { + 0, + { + NdrFcShort( 0x0 ), /* 0 */ +/* 2 */ + 0x11, 0x8, /* FC_RP [simple_pointer] */ +/* 4 */ + 0x22, /* FC_C_CSTRING */ + 0x5c, /* FC_PAD */ + + 0x0 + } + }; + +/* appease testlist.c */ +void func_stringinput_s() +{ +} -- -gmt

Jan. 4, 2003

interesting crash in msvc6.0 setup

by Dan Kegel

Since msvcmaker doesn't support msvc4.0, I'm trying to install msvc6.0 under wine. (Yeah, I know, I should run it under windows, but I'm stubborn.) Interestingly, the setup program puts itself in the background. This means you have to be careful to check with ps that you don't have old wines laying around from the last run, and when logging, you have to make sure all wine processes have exited, else your log file isn't complete yet. Unfortunately, setup fails fairly early. When emulating win9x, it fails before presenting a dialog box -- with a page fault reading from a file handle returned from CreateFile. It looks like it's doing an assembly string search on the Windows file structure pointed to by the handle! I wonder why. Maybe it was an easy way to prevent people from running under Wine :-) We may have to hack wine to make handles be valid pointers; I wonder what magic bytes setup is looking for there. When emulating winnt or winxp, it gets a bit further, but dies with a null pointer access. Oddly enough, adding --debugmsg +relay lets it proceed. It insists on installing Microsoft VM for Java, then tries to reboot. Restarting wine d:setup (this time without --debugmsg) continues properly for a while, but eventually crashes. Whenever it crashes in winnt/xp, it leaves one or more windowless wcmd's running the following script: :Repeat del "E:\vs60wiz.exe" if exist "E:\vs60wiz.exe" goto Repeat del "C:\WINDOWS\DEL4056.BAT" in a loop, chewing up huge amounts of CPU time. -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Menu problems

by Dimitrie O. Paun

Guys, All wxWindows examples exhibit a strange menu problem: upon startup, the main window has no menu, even if it should have. However, upon resize, the menu appears. Is this a known bug? -- Dimi.

Jan. 4, 2003

Re: WIP RPC test code (RFC): rpc_K01-pre2.diff

by Greg Turner

On Saturday 04 January 2003 03:58 pm, Eric Pouech wrote: > > o Failure in the child process doesn't cause failure of > > the test (is there someone else who has this solved > > for their test whose code I can borrow?) > > couldn't you test the output of GetExitProcess (and ensure that when > a test fails, we somehow return an error code) ? yes. (duh :) ) > > o rpcss.exe.so runs from the INSTALLED wine, not from > > the build tree!! This is totally unacceptable, but > > I'm not sure what would be a wise way to solve the > > problem. I need to change the way rpcss gets invoked > > by rpcrt4.dll. The best I can think of so far, would > > be to provide some global override (via a function > > call, I guess) for where rpcss.exe.so should be found, > > and then use this "feature" to ensure that during testing, > > rpcss.exe.so is invoked from the build tree instead of > > from the PATH environment variable. Any thoughts on this? > > what about an environment variable ? > we already use something like this for the wineserver (WINESERVER), > the wine console (WINECONSOLE)... why not rpcss (WINERPCSS) ? hmmm... will take a look at those, thanks. > > o There's a way to tell midl to deal with these namespace > > issues automagically so that the same .exe can be it's > > own client and server without a namespace conflict.... > > anyone know of such a feature? > > there isn't is ATM > however, MS' midl has a /prefix option that does just what you need > sounds like the way to go neato. sounds like a guaranteed winner :) > (another solution would be to put either client or server in a DLL > (in fact a wine builtin DLL) so that you separate the name space > between to two nice, also, maybe nicer... but surely this does not belong in "./dlls"? Will the makebeastie let me put it somewhere discreet like "./dlls/mydll/tests/dlls"? I kind of like the latter, also, because it allows me to kick around gazillions of conflicting namespaces, if need be. Anyhow, between the two of these I will surely find a winner. Thanks so much! You know how it goes, the mental bugzapper gets silently shut down by the Universal Power Glitchifier sometimes, I think it's back up again... -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Jan. 4, 2003

enhancement request - can msvcmaker generate a Makefile?

by Dan Kegel

Hi, I only have msvc4.0. It can't load the output of msvcmaker. I suppose I should buy current msvc, or modify msvcmaker myself to output a makefile instead of a project file. That's an idea... has anyone tried building the conformance tests with cl (i.e. microsoft's compiler's commandline interface)? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Re: Mac OS X/Darwin port of Wine

by Dan Kegel

Lionel Ulmer wrote: > I had once a long discussion with a fellow hacker on this subject (going > into the likes of using Valgrind's virtualization engine to output non-X86 > code to do dynamic translation and so on). We agreed that before starting > with Wine, one could start with running, for example, Linux/x86 binaries on > Linux/PPC. That would already validate the fact that you can draw the line > at one point and from there run such an heterogenous environment. Hey, that's a good idea. Then you could install and run x86 linux packages, if you were really lucky. Might be useful for running proprietary packages where they don't bother to rebuild for linux/ppc. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Re: problem using msvcmaker to build conformance test suite project file

by Dan Kegel

Patrik Stridvall wrote: >>http://www.winehq.com/Docs/wine-devel/testing-windows.shtml says: >> >> >>>Run msvcmaker to generate Visual C++ project files for >>>the tests. ... >>> >>>$ ./tools/winapi/msvcmaker --no-wine >> >>I did that in my cvs wine directory, and all I got was >>.: searching for /\.spec$/ >>.: searching for /^Makefile.in$/ >><internal>: options.pm: member W0B5 does not exists Aha. Caught by internationalization. The workaround is LANG=C export LANG ./tools/winapi/msvcmaker --no-wine I guess the FAQ needs updating... or the tool needs fixing... I suspect the easiest "fix" would be to wrap msvcmaker with LANG=C export LANG BTW, this is only one of many things that breaks when non-C locales are used. Others I know of: * 'man' when displayed in xterm or konsole (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75089 where Red Hat says they will not support xterm, and also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75642) * all text processing utils are 10x or more slower (makes it hard to grep through large log files) * sort gives nonintuitive results (not a bug, just very suprising) - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 4, 2003

Re: Windows Debugging Tools under Wine: "Could not inject logging thread into process"

by Sylvain Petreolle

of course not. but im trying to install .NET framework and its asking for msi update, that fail, even with these files installed. > I dunno. All I know is that copying all the msi* files > from my real windows/system directory to my fake windows/system > directory (and also copying cabinet.dll and using it) > made the installer work under cvs wine. So I guess yes. > Is that unusual ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 4, 2003