February 2004 - Wine-Devel - list.winehq.org

Re: NdrClientCall/format string interpreter/stubless proxies

by Robert Shearman

Hi Mike, I have implemented NdrClientCall/NdrClientCall2 and respective server functions and they are working fairly well (except for no exception handling and no pipe support). The thing that was blocking my submission of the patch was lack of testing. So far I have only tested on simple types and pointers to simple types. Full pointers have been implemented, but are not working correctly. I haven't had time to port my test program to the Wine test framework and test the rest of the types. I have been using references from MSDN on NDR format strings compared with my own tests based on code generated by MIDL. I have also used the OpenGroup DCE specification. (I have URLs for these, but not at hand and you can probably find them in my previous posts on the subject.) I will try to submit the patches tonight. Rob >>> Mike Hearn <mike(a)theoretic.com> 02/26/04 14:36 PM >>> Hi Rob, A few weeks back you mentioned you had done some work on implementing the stubless proxy entry points - can you explain a bit more about this? In particular, how far away are you from having something submittable, have you got docs on the format string syntax and how much are you intending to implement? thanks -mike

Feb. 26, 2004

NdrClientCall/format string interpreter/stubless proxies

by Mike Hearn

Hi Rob, A few weeks back you mentioned you had done some work on implementing the stubless proxy entry points - can you explain a bit more about this? In particular, how far away are you from having something submittable, have you got docs on the format string syntax and how much are you intending to implement? thanks -mike

Feb. 26, 2004

Re: crosstest compile fix (another)

by Hans Leidekker

On Thursday 26 February 2004 00:06, Stefan Leichter wrote: > I am sorry to tell you that the second way does not work for me. The error > message is attached (mingw.log). So i switched back to the Redhat version and > did > cd /usr/local ; ln -s /usr/mingw i386-mingw32 > and in /usr/bin i need the links > ln -s mingw-ar i386-mingw32-ar > ln -s mingw-ranlib i386-mingw32-ranlib Strange, I don't need those links. Is it only *-ar and *-ranlib or all of them? > Therefore i think the binutils package must be installed before building the > gcc package. Just checked that and yes, you're right. I've changed the web page and spec file accordingly. > Than i removed the Redhat packages and installed your runtime and my binutils > and gcc package and stat'rted building mingw-3.2. This fails with a linker > error (attached: user.log). It's the circular dependency again: you need to have MinGW installed in order to build it. I thought it was only the mingw-runtime package but it appears you need to have mingw-w32api installed as well. I've updated the web page to reflect this. This is a problem with the upstream sources by the way. Maybe we can solve this by splitting them up and reordering them a bit, don't know, but I will look into this. > I will try to build mingw-3.2 in the evening. Keep me posted. -Hans

Feb. 26, 2004

Re: Screenshot description

by Paul van Schayck

On Wednesday 25 February 2004 18:57, Dimitrie O. Paun wrote: > Well, having this XML only for description is a bit useless, > isn't it? But if you like it so much, why not use the XML > features, and give up on the restrictive naming: Yeah I agree. > <screenshot> > <thumb>wine_someimage.png</thumb> > <large>full/wine_someimage.png</large> > <description> > hey, you can write stuff here.. > </description> > </screenshot> > And if so, why stick them into shots/desc? Put them into shots/ directly, > they drive the entire thing. And we should move the thumbnails into a > thumb/ dir for consistency... No I think we should just make it possible to put them everywhere. This here above looks nice. So make a file screenshots.xml in the top directory with all paths and descriptions of all screens. And we can decide later where to put them. Regards, Paul

Feb. 26, 2004

Re: LOCALE: Don't copy value if buffer is too small

by Fabian Cenedese

>> Ok, I saw that you fixed the WCHAR/byte mess. But there is still a possibility that >> the function can copy a string longer than buffer if it already has an appended null. > >That shouldn't happen, NtQueryValue should have signaled an overflow >in that case. Do you have a test case showing the problem? Hmm.. not anymore. My program that failed works fine now. I started this patch when I assumed that the length argument is in bytes. But as you now changed all calls to WCHAR it doesn't even get to the copying anymore. So I'm sorry, forget that patch. Thanks bye Fabi

Feb. 26, 2004

Re: Native NetBSD audio driver

by Yorick Hardy

I was thinking to look at the integration of the oss and NetBSD drivers this weekend (following Eric and Dimi's suggestion). Should I rather wait until some restructuring is done? The inclusion of the NetBSD audio driver is not urgent since oss already works quite well, and it stagnated on my hard disk for months before I submitted anyway. I am not going to volunteer for the restructuring since I have a long overdue thesis to finish ;-). >> I think it might be worthwhile considering restructuring the audio >> drivers into hardware independent wave, direct sound, midi >> and mixer sections and a hardware dependent low level >> implementation for oss, alsa, ... > >Yes we should definitely do something like that. This sound driver >business is becoming a huge mess. Kind regards, Yorick Hardy. -------------------------------------------------------- This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R59. Free WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails Phone Now! 086 11 11 440

Feb. 26, 2004

Re: LOCALE: Don't copy value if buffer is too small

by Alexandre Julliard

Fabian Cenedese <Cenedese(a)indel.ch> writes: > Ok, I saw that you fixed the WCHAR/byte mess. But there is still a possibility that > the function can copy a string longer than buffer if it already has an appended null. That shouldn't happen, NtQueryValue should have signaled an overflow in that case. Do you have a test case showing the problem? -- Alexandre Julliard julliard(a)winehq.org

Feb. 26, 2004

Re: crosstest compile fix (another)

by Hans Leidekker

On Wednesday 25 February 2004 15:06, Stefan Leichter wrote: > The problem is that your package expects mingw install in /usr/local/ > i386-mingw32 but the Redhat one is in /usr/mingw. The error message is > attached. There are two ways out here. One is to change the install path to /usr/mingw in the spec file of gcc-mingw. I'm not going to do that myself because I think /usr/local/i386-mingw is a better choice (gcc-mingw is not part of the core distribution and old Unix wisdom says to put such stuff in /usr/local, i386-mingw is the official gcc target). The other way out for you is to install my ming-runtime package as I describe on my page that has the stuff in the right place to build gcc-mingw as is. By the way, if you succeed in building SUSE 9 RPMS I'm interested in putting those on my page. Could you send me the packages? -Hans

Feb. 26, 2004

Help needed to get the application work for native linux editors

by saravanan

Hai friends, I successfully ran a script manager(keyboard Manager/driver) developed for windows (using VC++) in Linux using wine. Its working in the wordpad application called using wine.I want to make it work in Linux editors. The technical details about the working of the keyboard driver is as follows. 1) The keyboard driver is a keyboard hooker program. The keyboard driver will trap all the keystrokes from the keyboard and convert the Ascii value to the appropriate native language Character code. 2) First we have to get the handle of the window/control where the cursor is currently located, for that the GetFocus API is used. 3) Virtual-key code of the key that generated the keystroke message is converted to appropriate another code for making the keyboard Inscript or phonetic and send using Postmessage API. I have some doubts. Do these APIs written for windows work in linux. In linux , How could i get the handle of the window where the cursor is currently located. What are the changes that i should make in the source code to make it work for linux editors. Looking for your suggessions. Thanks in advance . Saravanan ______________________________________ Scanned and protected by Email scanner

Feb. 26, 2004

Re: crosstest compile fix (another)

by Stefan Leichter

Am Donnerstag, 26. Februar 2004 03:45 schrieb Hans Leidekker: > On Wednesday 25 February 2004 15:06, Stefan Leichter wrote: > > The problem is that your package expects mingw install in /usr/local/ > > i386-mingw32 but the Redhat one is in /usr/mingw. The error message is > > attached. > > There are two ways out here. One is to change the install path > to /usr/mingw in the spec file of gcc-mingw. I'm not going to > do that myself because I think /usr/local/i386-mingw is a better > choice (gcc-mingw is not part of the core distribution and old > Unix wisdom says to put such stuff in /usr/local, i386-mingw is > the official gcc target). > > The other way out for you is to install my ming-runtime package as I > describe on my page that has the stuff in the right place to build > gcc-mingw as is. > I am sorry to tell you that the second way does not work for me. The error message is attached (mingw.log). So i switched back to the Redhat version and did cd /usr/local ; ln -s /usr/mingw i386-mingw32 and in /usr/bin i need the links ln -s mingw-ar i386-mingw32-ar ln -s mingw-ranlib i386-mingw32-ranlib Therefore i think the binutils package must be installed before building the gcc package. Than i removed the Redhat packages and installed your runtime and my binutils and gcc package and stat'rted building mingw-3.2. This fails with a linker error (attached: user.log). I will try to build mingw-3.2 in the evening. Bye Stefan

Feb. 25, 2004