Re: rpcrt4: Remove unreachable code in EmbeddedComplexSize.
2008/8/18 James McKenzie <[EMAIL PROTECTED]>: > Juan Lang wrote: >> Hi James, >> >> RPC_FC_ERROR_STATUS_T has a value of 0x10 and therefore isn't a possible value of "flags_type & 0xf" in the switch statement. >>> This may be a really stupid question, but is it possible to generate >>> this condition? >>> >> >> No, it isn't possible. 0xf & (any value) will never produce any value >> larger than 0xf. 0x10 > 0xf. >> > Juan: > > I meant is it possible to receive a RPC_FC_ERROR_STATUS_T (0x010) in > the original data before it is anded with 0x0f. If this is possible, > further changes may be needed. This data comes from the IDL compiler. The format is specified here: http://msdn.microsoft.com/en-us/library/aa379131(VS.85).aspx. If the IDL compiler tries to put RPC_FC_ERROR_STATUS_T into the type nibble then it is buggy. MIDL refuses to do so: .\test.idl(66) : error MIDL2072 : inapplicable attribute : [range] [ Type 'error_status_t' ( Parameter 'l' ) ] -- Rob Shearman
Re: How to use wine to load windows dll files ?
Gregory Hosler wrote: > Upon investigation, I've discovered that many of the routines that I'm linking > against are not in libwine.so, but instead, they are in other libraries. e.g. > /usr/lib/wine/user32.dll.so, /usr/lib/wine/winmm.dll.so, and a few others. > > > I would like to know how to link to and make use of these routines in the > respective wine libraries. I'm willing to write any stub code that might need > to > be written, but I cannot find any documentation of what needs to be done. > This topic keeps coming back every other week. The simple answer - no you can't link your native Linux program against Wine "libraries" and expect it to work. The long answer - Wine is not just set of libraries but an environment that have to be setup for windows applications (and Wine itself) to run properly. This includes "kernel"(wineserver), memory layout, files, registry, user objects, gdi, on and on and on. If you need only one small part from Wine - just take the code and adapt it. This is what mplayer did. Vitaliy.
How to use wine to load windows dll files ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I'm a developer of an open source project that needs to load some windows dlls for conversion routines. Specifically, I'm the lead developer of GyachI https://sourceforge.net/projects/gyachi/ a Yahoo Messenger client. In GyachI, in order to support speech in chat rooms, we make use of the window dll codec files (supplied by the end user) to do the necessary codec compression/decompression. At the present moment, we copied mplayer's method of loading the dll files. That is to say that we have some very old wine code in our source tree. It works, but as and when a user runs GyachI on a box with wine installed, then GyachI will run against the installed wine libraries instead of the inbuilt wine code (not sure how, but this seems to be the case, from several reports). Since the code that we're using is all wine code, and in fact it is in the wine libraries, I would like to purge the wine code out of our project tree, and just compile/link against the necessary wine header files / wine libraries. To that extent, I have been able to remove the wine code from a build tree, and using the wine header files, I can get my code to compile. However, when I go to link, I get a number of undefined symbols. Some of the undefined symbols (at link time) are: undefined reference to `CloseDriver' undefined reference to `CodecAlloc' undefined reference to `CodecRelease' undefined reference to `export_names' undefined reference to `GetProcAddress' undefined reference to `HeapAlloc' undefined reference to `HeapFree' undefined reference to `OpenDriverA' undefined reference to `SendDriverMessage' undefined reference to `__vprintf' Upon investigation, I've discovered that many of the routines that I'm linking against are not in libwine.so, but instead, they are in other libraries. e.g. /usr/lib/wine/user32.dll.so, /usr/lib/wine/winmm.dll.so, and a few others. I would like to know how to link to and make use of these routines in the respective wine libraries. I'm willing to write any stub code that might need to be written, but I cannot find any documentation of what needs to be done. Any suggestions, pointers, links, urls, etc., would be most appreciated. Code samples (e.g. from other projects doing what I'm trying to do) would also be much appreciated. :) Many thanks, and best rgds, - -Greg - -- +-+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIqQJ6404fl/0CV/QRAivBAJ0c66W7ePiItK8ZvNnZ/1nLErSWKwCfRRD7 PbePRptt6e8mEEefwRx2YsE= =euK4 -END PGP SIGNATURE-
Re: New kernel development guide might be good model for Wine...
On Sun, Aug 17, 2008 at 11:45 PM, Hongbo Ni <[EMAIL PROTECTED]> wrote: > "Dan Kegel" > wrote: > This guide seems rather well written: > > http://ldn.linuxfoundation.org/how-participate-linux-community > Wine could > probably use something similar. YES, the Wine development speed can be > greatly improved if similar development process is adepted, specially the > 'Chain of Commands'. I am sure that Alexandre has done a great job as the > Wine maintainer, but he may be stressed out when he come back from his > holiday as there are pile of patches awaiting him to review and commit. > Hongbo Ni > I don't believe that was Dan's intention when he referred to that document. Dan is saying that the overall format of the document is helpful, and we should write our own version of it that matches the Wine development process. We can always use more help, but for the developers we do have, we're developing at a speedy pace. Also, Julliard hasn't had trouble scaling with the pace of development so far. We just need to write down this process in words in order to reduce the learning curve that keeps developers away from successful Wine development. -- James Hawkins
[no subject]
Sorry my previous email got wrong format. "Dan Kegel" wrote: > This guide seems rather well written: > http://ldn.linuxfoundation.org/how-participate-linux-community > Wine could probably use something similar. YES, the Wine development speed can be greatly improved if similar development process is adepted, specially the 'Chain of Commands'. I am sure that Alexandre has done a great job as the Wine maintainer, but he may be stressed out when he comes back from his holiday as there are pile of patches awaiting him to review and commit. Hongbo Ni _ Win a Nokia E51 with mobile Hotmail SMS alerts http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4589
RE: New kernel development guide might be good model for Wine...
"Dan Kegel" <[EMAIL PROTECTED]> wrote: > This guide seems rather well written: > http://ldn.linuxfoundation.org/how-participate-linux-community > Wine could probably use something similar. YES, the Wine development speed can be greatly improved if similar development process is adepted, specially the 'Chain of Commands'. I am sure that Alexandre has done a great job as the Wine maintainer, but he may be stressed out when he come back from his holiday as there are pile of patches awaiting him to review and commit. Hongbo Ni _ Win a Nokia E51 with mobile Hotmail SMS alerts http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4589
Re: rpcrt4: Remove unreachable code in EmbeddedComplexSize.
Juan Lang wrote: > Hi James, > > >>> RPC_FC_ERROR_STATUS_T has a value of 0x10 and therefore isn't a >>> possible value of "flags_type & 0xf" in the switch statement. >>> >> This may be a really stupid question, but is it possible to generate >> this condition? >> > > No, it isn't possible. 0xf & (any value) will never produce any value > larger than 0xf. 0x10 > 0xf. > Juan: I meant is it possible to receive a RPC_FC_ERROR_STATUS_T (0x010) in the original data before it is anded with 0x0f. If this is possible, further changes may be needed. James McKenzie
Re: .NET program crashes involving stubbed functions
Adam Petaccia wrote: > On Wed, 2008-08-13 at 19:32 +0100, Reece Dunn wrote: > >> 2008/8/13 Adam Petaccia <[EMAIL PROTECTED]>: >> >>> Its customary to make a function return NotImplemented in Gdiplus, if >>> its just a dummy function that does nothing and returns. But .NET seems >>> to check for this and throw an exception, crashing the program anyway. >>> >>> See bug http://bugs.winehq.org/show_bug.cgi?id=12951 for details, but >>> originally a program crashed because GdipNewPrivateFontCollection was >>> just a stub. After the function was created, it still crashes because it >>> returns "NotImplemented", rather than "Ok". IIRC, we return >>> "NotImplemented" for some debugging reason, but if the goal of Wine is >>> to run Windows applications, should we just go ahead and return "Ok" so >>> that .NET apps don't freak out? >>> >>> Of course in a perfect world, we wouldn't have to fake a return code, >>> but until that time comes do people have opinions one way or another? >>> >> The problem with returning Ok is that it implies that the function >> succeeded in what it is intended to do. As a result, the application >> will continue and in this case expect to be able to use the private >> font collection. To prevent the application crashing, it is likely >> that several functions will need to be implemented. >> >> Also note that the reporter of the bug mentions that they installed >> mono. This means that using MS.NET may lead to different behaviour. It >> also means that it should be possible to see how the >> GdipNewPrivateFontCollection call is being used by mono and the data >> that it returns. >> >> So to summarise, I suspect this will require more than simply >> returning Ok. >> > Most likely in this particular case you would be correct. But the whole > reason we have stubs is so that (C/C++) programs don't crash, but try to > move on, possibly with impaired functionality, but (at least with mono) > this does absolutely zero good as the program terminates anyway, but > this time for a different reason. > What actually happens with Mono? > On a side note, I thought Wine's preferred .NET was mono anyway. > > No, we are trying to implement .NET as some programs will not work with Mono, either. It looks like your program is one of them. James McKenzie
Re: rpcrt4: Remove unreachable code in EmbeddedComplexSize.
Hi James, >> RPC_FC_ERROR_STATUS_T has a value of 0x10 and therefore isn't a >> possible value of "flags_type & 0xf" in the switch statement. > > This may be a really stupid question, but is it possible to generate > this condition? No, it isn't possible. 0xf & (any value) will never produce any value larger than 0xf. 0x10 > 0xf. --Juan
Re: rpcrt4: Remove unreachable code in EmbeddedComplexSize.
Rob Shearman wrote: > RPC_FC_ERROR_STATUS_T has a value of 0x10 and therefore isn't a > possible value of "flags_type & 0xf" in the switch statement. > Rob: This may be a really stupid question, but is it possible to generate this condition? James McKenzie
Re: Patchwatcher status
On Thursday 14 August 2008 16:38:40 Dan Kegel wrote: > What to do, what to do... how about this: are there any python users > on the list who would be willing to help adapt buildbot to our needs? I've subscribed to the buildbot list as well, and I'll start looking over the code once I figured out which VCS to install to get the latest greatest buildbot code. I wish people out there could just agree on which VCS is best and use git. ;) If I get the api docs right, the best option seems to be to subclass their mailwatcher to trigger the try --diff. The hardest part will be getting the patch series logic to work or possibly keeping track of the regression tests. On the plus side, it should be possible to run buildslave instances on win32, so perhaps there's a decent way to build and run the tests on win32 native right away as well. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Patchwatcher status
Patchwatcher falsely complained that
[2/17] richedit: Removed assumption about the order of rtf indent
didn't apply because the regexp I used to detect
the end of a patch series falsely matched the
first patch in a series of 1x patches. Here's the fix:
--- patchwatcher.sh (revision 150)
+++ patchwatcher.sh (working copy)
@@ -283,7 +283,7 @@
cat $PATCHES/$NEXT.log
fi
# Use a regexp with a back reference to detect last patch in
a series and break out
-if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt && !
egrep -q 'Subject:.*([0-9]+)/\1' $PATCHES/$NEXT.txt
+if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt && !
egrep -q 'Subject:.*([0-9]+)/\1[^0-9]' $PATCHES/$NEXT.txt
then
echo In middle of patch series, not wiping tree
NEXT=`expr $NEXT + 1`
And it falsely complained that various of [EMAIL PROTECTED]'s
patches failed because it didn't handle the case of multiple
patch series sent by the same author back to back and mixed
together by email delays. Here's a fix:
--- get-patches.pl (revision 150)
+++ get-patches.pl (working copy)
@@ -147,7 +147,7 @@
$series_num_patches = $num_patches;
}
-if ($series_sender ne $sender) {
+if ($series_sender ne $sender || $series_num_patches != $num_patches) {
#print "Ignoring series for now, will try later; sender
$sender, num_patches $num_patches, subject
".$header->get('Subject')."\n";
# can't handle multiple series at once just yet, let it sit
return;
That still won't handle the case of two patch series of the same length
being sent back to back by the same author, but that's
ambiguous enough that even humans might be confused,
so it should tide us over until I rewrite the patch series
detector to handle incomplete series better.
I'm on vacation so I can't apply these patches to the running instance,
I'll do it on tuesday.
- Dan
Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 3)
Am Samstag, den 16.08.2008, 23:56 + schrieb Louis. Lenders: > Hi Michael, thanks again for the comment, i moved the check for the > stringlength to the front, and removed the wrong check for the > bufferlength (oops). Looks quite good now, but somehow the "return TRUE;" line got lost. Regards, Michael Karcher
