Wine-Devel
By thread
wine-devel@list.winehq.org
By month
Messages by month
- ----- 2026 -----
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
January 2003
- 151 participants
- 1149 messages
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