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

Authors.c Won't Compile
by Robert Shearman Feb. 27, 2004

Feb. 27, 2004

Hi, I can't compile authors.c due to some encoding issue with sed. I can generate the authors.c file fine on the command line, but the same command in the Makefile won't generate compilable code due to it terminating the string constant before a UTF-8 character. Rob Example of errors: authors.c:19: error: stray '\366' in program authors.c:20: error: `m' undeclared here (not in a function) authors.c:20: error: initializer element is not constant authors.c:20: error: (near initialization for `SHELL_Authors[18]') authors.c:20: error: syntax error before string constant

1 0

Re: time: rework of GetLocalTime speedup
by Steven Edwards Feb. 26, 2004

Feb. 26, 2004

--- Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: > Huw Davies <huw(a)codeweavers.com> > Cache the result of TIME_GetBias for upto 1 second. Hello Huw, I know you may not have a lot of time =P but while you are working on the Wine time implementation could you look at rpcrt4 and its use of gettimeofday? Most of the WINE rpcrt4 implementation should be portable to Windows/ReactOS but currently I have to use a hacked implementation of this function and would rather it use the Win32 or NT api. Thanks Steven __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools

1 0

Screenshot description
by Paul van Schayck Feb. 26, 2004

Feb. 26, 2004

Hey, Wouldn't it be nice to have a description of every screen at the screenshot page of winehq.com? To know what you see, I don't know half the programs I see on those screens. I have made a patch for the site file. The patch needs a a description.txt file inside /images/shots/ in this form: [screen# out of the filename]|[screen dexcription] Example: "1|Wine doing default Windows programs" Next descriptions on a new line. I've not edited the template but the patch adds a $des_[#] to the available vars. This is my first attemp to do something for winehq. So, are you interested in descriptions for screenshots? Regards, Paul van Schayck

3 6

Proposal: new mailing list wine-gov@winehq.org
by Dan Kegel Feb. 26, 2004

Feb. 26, 2004

City governments (especially in Germany and France) have recently begun seriously consider migrating to Linux, and feasibility studies are being done and to some extent are publically available. The study done for Munich, for instance, recognizes that cities need sometimes hundreds of specialized software packages that are not yet available for Linux, and so the cities will have to continue running the Windows versions of those apps for the time being. Yet it suggests using Terminal Services and/or VmWare to run those apps! Clearly, the Wine community needs to make an effort to address the needs of city governments and to get the word out that Wine is a viable option. One important part of this effort should be a mailing list akin to wine-users but dedicated to governmental users of Wine. (wine-users is full of all sorts of topics that might not mix well with staid government workers; some of the games discussed there might even be banned in Germany!) Dedicating a mailing list to this special category of user would greatly increase the signal-to-noise ratio, and should increase the likelihood that government users would feel comfortable about Wine. IMHO the list should allow posts in any language; if nobody can handle the language a post is in, we'll ask the poster to try again in English. The goal here is to avoid intimidating these possibly skittish users; asking them to *always* post in English might scare some of them away. Comments? Thanks, Dan -- US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/

4 5

Re: NdrClientCall/format string interpreter/stubless proxies
by Robert Shearman Feb. 26, 2004

Feb. 26, 2004

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

1 0

NdrClientCall/format string interpreter/stubless proxies
by Mike Hearn Feb. 26, 2004

Feb. 26, 2004

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

1 0

Re: crosstest compile fix (another)
by Hans Leidekker Feb. 26, 2004

Feb. 26, 2004

On Sunday 22 February 2004 15:17, Stefan Leichter wrote: > as pointed out from Hans Leidekker (http://www.winehq.org/hypermail/ > wine-devel/2004/02/0448.html) mingw misses some GUID in its header files Well, it was a patch to MinGW and I don't think we should work around this shortcoming of MinGW by patching Wine. On the other hand, MinGW is still not useful for us even if we're sending them patches to fix things every now and then. That, and the poor or outdated state of MinGW RPM packages, and the plans for a PE build of Wine lead me to ask myself the question 'Why don't we build our own MinGW cross compiler packages?' That way we could have a working MinGW on RPM based distros as well and we can throw in couple of patches of our own to make it useful for compiling Wine. Not to create a fork of course, but more like what Redhat does, i.e. still trying to get patches accepted upstream. I have been working on these RPMS already and plan on putting up a page somewhere shortly. Initial goal is to compile all Wine tests out of the box. -Hans

4 8

Re: LOCALE: Don't copy value if buffer is too small
by Alexandre Julliard Feb. 26, 2004

Feb. 26, 2004

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

2 1

Re: Native NetBSD audio driver
by Yorick Hardy Feb. 26, 2004

Feb. 26, 2004

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

1 0

Help needed to get the application work for native linux editors
by saravanan Feb. 26, 2004

Feb. 26, 2004

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

1 0