wine-devel February 2004

wine-devel@winehq.org

132 participants
261 discussions

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

27 Feb '04

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 26 Feb '04

26 Feb '04

--- 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 26 Feb '04

26 Feb '04

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 26 Feb '04

26 Feb '04

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 26 Feb '04

26 Feb '04

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 26 Feb '04

26 Feb '04

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 26 Feb '04

26 Feb '04

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 26 Feb '04

26 Feb '04

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 26 Feb '04

26 Feb '04

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

Re: DCE: LockWindowUpdate
by Mike Hearn 25 Feb '04

25 Feb '04

Hi Ken, I'm really sorry about this but I already implemented LockWindowUpdate about a month or two ago. Unfortunately it is blocking on moving invalidation handling into the wineserver, and was not applied. So, I'm afraid that (a) the work has already been done and (b) the patch you sent, is wrong. I made the same mistake at first - unfortunately LockWindowUpdate is a global thing, ie the locked window is held in-kernel on Windows. Alexandre: I said at the time we should apply the patch I sent but disable it, so it doesn't get lost/forgotten about. Here's another reason we should do that - it'll stop people reimplementing what has already been done. thanks -mike On Wed, 25 Feb 2004 13:28:19 -0500, Ken Belleau wrote: > When there is a locked window, GetDCEx and related functions now returns > DCs with an empty visible region unless DCX_LOCKWINDOWUPDATE is > specified.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2004