wine-devel July 2004

wine-devel@winehq.org

122 participants
251 discussions

Question about mmap issues on FreeBSD/NetBSD
by Yorick Hardy 29 Jul '04

29 Jul '04

Just a question about the mmap issues experienced on FreeBSD, i.e. http://www.winehq.org/?issue=230#Wine%20on%20FreeBSD I encountered the same on NetBSD. It seems the error message is set from ld.elf_so in NetBSD and ld-elf.so.1 in FreeBSD, when the address space is mapped for the run time linking? Since MAP_NORESERVE is not documented (and not supported?) for mmap on FreeBSD and NetBSD, it would appear that wine and the ld.elf_so together require too much memory for all the mmap calls. Am I correct? Kind regards, -- Yorick Hardy

2 1

Re: Is bugzilla worth keeping?
by Dan Kegel 29 Jul '04

29 Jul '04

Mike Hearn wrote: > So are we misleading users by having a bugzilla into thinking that if > they file a bug there, it'll be fixed when it probably won't? Not at all. Just because not enough people are doing bug triage or fixing doesn't mean we should drop bugzilla. Somebody will eventually go through the bug reports, I think. > If we were to simply drop bugzilla, how would it impact the project? It would deprive us of long-term memory. For instance, I filed the bug report http://bugs.winehq.org/show_bug.cgi?id=1404 in January 2003 with a nice test case (but one that's hard to translate into a unit test). Without Bugzilla, we'd have a harder time remembering problems like that. (Unless cxtest really takes off, I suppose...) - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 3

Re: winetests/winrash
by Rolf Kalbermatter 29 Jul '04

29 Jul '04

Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: >I wouldn't mind adding a systray icon. I wasn't really sure how that was >supposed to be done. I tried having the service add a systray icon without >much success, I don't believe services can interact with the desktop. That >may mean that a separate winrash monitor may have to be written that >communicates with the service. Services can interact with the desktop but not by default. It is a special option you specify when installing the service. The magic for this is in the dwServiceType parameter of the CreateService() to register a service object in the system. >From MSDN: SERVICE_FILE_SYSTEM_DRIVER File system driver service. SERVICE_KERNEL_DRIVER Driver service. SERVICE_WIN32_OWN_PROCESS Service that runs in its own process. SERVICE_WIN32_SHARE_PROCESS Service that shares a process with one or more other services. For more information, see Service Programs. If you specify either SERVICE_WIN32_OWN_PROCESS or SERVICE_WIN32_SHARE_PROCESS, and the service is running in the context of the LocalSystem account, you can also specify the following type. Type Meaning SERVICE_INTERACTIVE_PROCESS The service can interact with the desktop. Not sure how winrash is currently installed but if it is not through a small Win32 setup app but an InstallShield app, I'm sure it has according parameters to let it install as interactive service Rolf Kalbermatter

2 1

Fwd: Re: rsabase.dll
by Michael Jung 29 Jul '04

29 Jul '04

I'm sorry, if this mail appears three times on the wine-devel list. I've sent it twice already, but it doesn't seem to get forwarded to the wine-devel list. Is there a problem with the mailing list? Rob, could you give me a short notificaton, if you have received those mails? Thank, Michael ---------- Forwarded Message ---------- Subject: Re: rsabase.dll Date: Tuesday 27 July 2004 10:08 From: Michael Jung <mjung(a)iss.tu-darmstadt.de> To: wine-devel(a)winehq.org Cc: rob(a)codeweavers.com Rob, > I think there are many reasons to favour "real handles": If a long running > process is using rsabase (e.g. a webserver serving https: requests) with > many temporary connections and many keys, resource leakage is an issue. > Furthermore, since rsabase is a cryptographic service provider, it might be > important that a key, which is not referenced anymore is in fact destroyed > (and the > corresponding memory be nulled). I would think that otherwise you will > over time accumulate a lot of keys in your address space, which is probably > a security problem. Now, I'm aware that wine is not in a state today to be > used for security critical applications and first rsabase implementations > will probably have security issues more severe than this. However, sometime > I think rsabase will have to use real handles. Why not right from the > start? I've thought about this statement again and realized that I'm wrong and that I probably misunderstood you. I realized that one doesn't need "real handles" in user mode code at all to implement correct resource management. And I think I understand that one does need them in the kernel (aka wineserver) for objects, which are accessed from multiple threads. However, there are some instances of "real handle" implementations outside wineserver in wine (e.g. dlls/msi/handle.c). Do you (or anybody else on the mailing list) now what for? Some things, which I could imagine would still be easier to implement correctly with "real handles", are the INVALID_HANDLE_VALUE value, checking that a thread does not access a resource via an already released handle and in general checking in a precise manner if a handle value is valid (which, as I understand it, is often done in wine with a magic value at the beginning of the object.) Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

1 0

Is bugzilla worth keeping?
by Mike Hearn 29 Jul '04

29 Jul '04

One thing I notice about most other open source projects is that they have many more flamewars than we do. So, I thought I'd start one: It strikes me, looking at the wine-bugs list, that there is a huge disparity between the number of people maintaining it and the number of people filing bugs in it. It seems to be quite rare for communication on bugfixes to take place there, wine-devel is the more usual forum. So are we misleading users by having a bugzilla into thinking that if they file a bug there, it'll be fixed when it probably won't? If so, does it matter? If we were to simply drop bugzilla, how would it impact the project? Thoughts, anybody? thanks -mike

10 10

winetests/winrash
by James Hawkins 29 Jul '04

29 Jul '04

What is it exactly that winrash does? Is it running winetests using the native libraries of the Windows operating system that the user is running the tests on, or are the wine libraries being tested through some means? Is there a site where this information is readily available? I have one suggestion: users typically like to see results when they volunteer their computer time to a project such as this, which is understandable, so a future version might benefit from a system tray icon that can be opened up to see the test running and/or display results of the tests that have been run. -- James Hawkins

2 1

How do we handle unicode (utf-8) codepages?
by Shachar Shemesh 29 Jul '04

29 Jul '04

What do we do if the user requests a Unicode codepage? I've just had a conversation with a user on IRC where I believe things didn't work for him because LANG was set to es_ES.UTF-8. On one hand, I don't think we can force ANSI applications to work in Unicode. On the other hand, we cannot change the locale - it will mean noone (whether ANSI or not) will not be able to access non-ASCII file names and files. Comments? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

2 1

Re: Re: WineHQ:service.cgi: fix winrash option
by chmorgan＠charter.net 28 Jul '04

28 Jul '04

Which errors are you referring to? The most frequent ones lately are the ones where the winetest package isn't available on the sourceforge osdn mirror. We are still asking people to download the tests from this location for particular test releases. I'd imagine the fix is simply to point the downloads at valid mirror for the file. Chris > > From: Ferenc Wagner <wferi(a)afavant.elte.hu> > Date: 2004/07/26 Mon AM 07:57:51 EDT > To: wine-devel(a)winehq.org > CC: <wine-patches(a)winehq.com>, <cmorgan(a)alum.WPI.EDU> > Subject: Re: WineHQ:service.cgi: fix winrash option > > <chmorgan(a)charter.net> writes: > > > What is the service doing with winrash options btw? The > > installer stops, installs and starts the winrash service. > > > > The installer uses /S for silent installs, otherwise it > > will try to popup windows. Are you sure the service isn't > > calling the installer with /S? > > You are right, I was wrong. This patch is rubbish. I can't > really understand the errors on wine-test-results. Have you > got an idea what may have gone wrong? Aren't any functional > winrash instances running? Is something broken in the > service script? The documentation is somewhat scarce so I'm > doing a slow start... > -- > Feri. > >

2 1

Re: DCOM: Fix Ref Counting in StdMarshalImpl_MarshalInterface
by Robert Shearman 28 Jul '04

28 Jul '04

Robert Shearman wrote: > Changelog: > > Mike Hearn <mh(a)codeweavers.com> > Fix ref counting in StdMarshalImpl_MarshalInterface for case where the > stub already exists. > >Index: wine/dlls/ole32/compobj_private.h >=================================================================== >RCS file: /home/wine/wine/dlls/ole32/compobj_private.h,v >retrieving revision 1.14 > Oops. Wrong patch. Rob

1 0

Re: COM RPC: Fix Infinite Loop
by Robert Shearman 28 Jul '04

28 Jul '04

Robert Shearman wrote: > Changelog: > Fix for infinite loop that could occur if _invoke_onereq failed. Please don't apply this patch. I'll submit a better and more complete one in a minute. Rob

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
26
Older →

Jump to page:

2025

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 July 2004