wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: shlapi: Fixes for UrlIsW and UrlIsA
by Andreas Mohr 14 Mar '05

14 Mar '05

Hi, On Mon, Mar 14, 2005 at 09:07:57PM +1100, Troy Rollo wrote: > Testing under Windows shows that UrlIsW and UrlIsA should: Since you already did testing under Windows, adding proper tests would make sense, I guess... Or in other words: I'm not sure whether your current patch would get applied. Andreas Mohr

1 0

Re: wine/ misc/registry.c documentation/samples/config
by Steven Edwards 14 Mar '05

14 Mar '05

Hi, --- Mike McCormack <mike(a)codeweavers.com> wrote: > People would moan and complain, but in the end Wine and Wine users would > be better off, as they would no longer depend on anything but Wine to > run their Windows software. I have to agree. Short term being able to load the Windows registry and Windows system dlls helped Wine but long term it has led to stagnation. Most of the recent growth in Wine in past few years has been because we are being forced to not be dependant on a existing Windows install or Windows componates such as DCOM IE, MSI, etc which is a good thing. Thanks Steven __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

8 13

[ARTWORK] icon: "My Computer"
by egore 14 Mar '05

14 Mar '05

Hi list, I drew a simple icon that COULD be used as a replacement for the current one. I don't know if anyone of you likes it, so please tell me what you think. Tell me if you like it, if you hate if, what could be done better, etc. The icon can be found in different sizes (and in a scalable format) at http://www.egore911.de/vype/wine/ Regards, Christoph Brill aka egore911

6 6

Re: Wine Start Menu in the Desktop Applications Menu
by Dan Kegel 14 Mar '05

14 Mar '05

Jeff Waugh (jeff.waugh_at_ubuntu.com) wrote: >> The PowerPC version of the packages, however, is another issue. >> Obviously, we can't make Wine work with i386-compiled apps on PPC, > > (There's an awesome opportunity for qemu integration there...) Yeah, that's something the folks at http://darwine.opendarwin.org have been thinking about for some time, and to some extent trying. You might give them a shout... - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Re: [X11DRV] Fix X11 Device list leak
by rob 14 Mar '05

14 Mar '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Raphael fenix-at-club-internet.fr |Wine Mailing Lists| wrote: |Hi, | |Changelog: | - XListInputDevices spec say that device list should be freed using |XFreeDeviceList | - better robustness on X11DRV_AttachEventQueueToTablet | |I hope it helps to fix bug 2017 (http://bugs.winehq.org/show_bug.cgi?id=2017) | |Regards, |Raphael Thanks for submitting this patch. These are exactly the fixes I was about to submit! Your patch should should have a major impact on users of applications which use the wintab library: They should all start to function to some degree. Apologies for not commenting on patch/ submitting a fix earlier.... A major knee operation has put me out of action for the last few weeks. P.S. Please don't expect timely responses to mails for at least another week. I'll try my best to respond, but can't promise anything. Cheers ~ -Rob. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCNPgCKeDvIR8zB68RAgQ3AJ9BA00ZgtZd/HXWy0nOPa3xpWaO3QCfcvVJ RC2lSu6lgqZocJkohkYi/WE= =fFJD -----END PGP SIGNATURE-----

1 0

Re: Borland C++ Buildeer under Wine
by Oliver Stieber 14 Mar '05

14 Mar '05

--- Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > It's an old version - 3 IIRC. It starts, but the > Borland window (menu > bar across top) flickers and no other windows open. > I'll see if I've got a copy on a cover disk. CBuilder defiantly used to work. > Andrew > > > > Oliver Stieber wrote: > > --- Andrew Neil Ramage > <nrsc16850(a)blueyonder.co.uk> > > wrote: > > > >>Below is the last three lines of error messages > >>printed when I tried to > >>run Borland C++ Builder under wine. (There were > >>pages and pages of > >>error messages after I hit Ctrl-C in the terminal > I > >>had started BCB.EXE > >>from.) > >> > >>Is this a known bug in Wine ? > >> > >>err:syslevel:_EnterSysLevel (0x40797840, level 2): > >>Holding 0x4083ccc0, > >>level 3. Expect deadlock! > >>err:syslevel:_CheckNotSysLevel Holding lock > >>0x4083ccc0 level 3 > >>err:seh:setup_exception stack overflow 176 bytes > in > >>thread 0009 eip > >>004078d5 esp 405b0f50 stack 0x405b0000-0x406b0000 > >>[andrew@zeus BIN]$ > >> > > > > The stack overflow looks like somethings got stuck > in > > a loop, which is problably why there were pages > and > > pages of messages. > > > > What version of CBuilder are you using, CBuilder > <=5 > > used to work. > > > > > http://www.borland.com/products/downloads/download_cbuilderx.html > > CBuilder X claims to run on linux OOTB. > > > > > > I've got standard on the shelf, > > > >>-- > >> > >>Andrew > >> > >>[hackcoughsniffle] > >>Internal Virus Database corrupt > >> > >> > > > > > > Send instant messages to your online friends > http://uk.messenger.yahoo.com > > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: Borland C++ Buildeer under Wine
by Oliver Stieber 14 Mar '05

14 Mar '05

1 0

Re: [documentation] winedev-kernel
by Dmitry Timoshkov 13 Mar '05

13 Mar '05

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > + <title>File management</title> > + <para> > + With time, Windows API comes closer to the old Unix paradigm "Everything > + is a file". Even if it grew better over the years, it's still not 100% > + there (for example, you cannot use <function>ReadFile()</function> over > + a socket handle). Is it really true? >From MSDN: BOOL ReadFile( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped ); Parameters hFile [in] Handle to the file to be read. The file handle must have been created with the GENERIC_READ access right. For more information, see File Security and Access Rights. For asynchronous read operations, hFile can be any handle opened with the FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket handle returned by the socket or accept function. -- Dmitry.

3 6

Help fixing updown (comctl32) bug?
by C. Scott Ananian 13 Mar '05

13 Mar '05

I have an open-source Windows application I'm trying to get to run under Wine (sd -- it's in the wine applications database). The particular issue I'd dealing with (at the moment) is a UDM_GETPOS message to an updown control. This is the code in the source application. ui_options.sequence_num_override = SendMessage(GetDlgItem(hwnd, IDC_SEQ_NUM_OVERRIDE_SPIN), UDM_GETPOS, 0, 0L); Under windows, when you just click 'ok' on the dialog without touching the updown control, this SendMessage returns '0'. Under wine, it returns 65536. Looking at the code (wine-cvs/dlls/comctl32/updown.c:2049): case UDM_GETPOS: temp = UPDOWN_GetBuddyInt (infoPtr); return MAKELONG(infoPtr->CurVal, temp ? 0 : 1); So, the different between Windows and Wine is that 'GetBuddyInt' (or its equivalent on Windows) is returning TRUE on Windows and FALSE in Wine. Digging down a level, the first lines of code in UPDOWN_GetBuddyInt are (wine-cvs/dlls/comctl32/updown.c:267): static BOOL UPDOWN_GetBuddyInt (UPDOWN_INFO *infoPtr) { WCHAR txt[20], sep, *src, *dst; int newVal; if (!IsWindow(infoPtr->Buddy)) return FALSE; ------- tracing through GetBuddyInt in Wine, this is as far as it gets. IsWindow returns FALSE, and so GetBuddyInt returns FALSE. But this is very puzzling: if I click one of the controls on the updown control, GetBuddyInt will eventually return TRUE. I don't really understand the purpose of the 'IsWindow' call here -- can anyone who understands the code a bit better explain to me how infoPtr->Buddy could get 'de-windowized'? I don't see anyplace in the code where Buddy gets reassigned, and turning on tracing doesn't show anything suspicious, and I've having great trouble getting gdb to set an appropriate watchpoint for me. Does anyone else have any insights? --scott KUCAGE KMPLEBE class struggle Cocaine UKUSA SCRANGER early warning colonel Bejing AELADLE LICOZY for Dummies ammunition ESODIC Treasury ( http://cscott.net/ )

1 0

Winston.exe or Elster-Formular
by Dietrich Teickner 13 Mar '05

13 Mar '05

Has anyone tested "Winston" with wine ? This is a replacement for the german tax-program "Elster". If yes, how does the internet-connection works ? Inside Odin(wine-for os\2) overwrites any os-function the WSALastError ( redirected LastError) with any LastError. I know Wine works in the same manner. After redirect the WSALastError to any Tls (only for test), "Winston" will work. Dietrich

2 1

Re: [documentation] winedev-kernel
by Dimitrie O. Paun 13 Mar '05

13 Mar '05

On Sat, Mar 12, 2005 at 09:29:44PM +0100, Eric Pouech wrote: > some DocBook cosmetic stuff, and new docu (file management being the most > important one) Very nice! Does this complete task Documentation/Devel Guide/6 on the TODO list? -- Dimi.

2 2

Re: Borland C++ Buildeer under Wine
by Oliver Stieber 13 Mar '05

13 Mar '05

--- Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > Below is the last three lines of error messages > printed when I tried to > run Borland C++ Builder under wine. (There were > pages and pages of > error messages after I hit Ctrl-C in the terminal I > had started BCB.EXE > from.) > > Is this a known bug in Wine ? > > err:syslevel:_EnterSysLevel (0x40797840, level 2): > Holding 0x4083ccc0, > level 3. Expect deadlock! > err:syslevel:_CheckNotSysLevel Holding lock > 0x4083ccc0 level 3 > err:seh:setup_exception stack overflow 176 bytes in > thread 0009 eip > 004078d5 esp 405b0f50 stack 0x405b0000-0x406b0000 > [andrew@zeus BIN]$ > The stack overflow looks like somethings got stuck in a loop, which is problably why there were pages and pages of messages. What version of CBuilder are you using, CBuilder <=5 used to work. http://www.borland.com/products/downloads/download_cbuilderx.html CBuilder X claims to run on linux OOTB. I've got standard on the shelf, > -- > > Andrew > > [hackcoughsniffle] > Internal Virus Database corrupt > > Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1

Re: Wine Start Menu in the Desktop Applications Menu
by Mike Hearn 13 Mar '05

13 Mar '05

On Sat, 12 Mar 2005 18:09:52 -0800, Scott Ritchie wrote: > We've talked about it on the Wine lists before, but there have been some > difficulties. The first is that we don't yet understand how to read > Windows shortcut files and interpret them: this can probably be overcome > with some work. Really? That's news to me. We can read .lnk files just fine and even produce .desktop files for them, that's where the icons on the desktop come from. > Here, I propose a short plan of action for getting Wine applications > into the Applications menu. Some of these need to be done at the > distribution level and some need to be done within Wine. When we have > it working nice and smoothly we can submit whatever changes we made to > freedesktop.org as well if they need to become a cross-distribution > standard. > > Here's how I see we can do this in Ubuntu: > > 1) Create a new Menu entry in the .menu file > at /usr/share/gnome-app-install/applications.menu This one will be > named "Windows Applications" and will need to point to two locations > for .desktop files: system-wide ones, and user-specific ones. > Instructions for how to do this are here: > http://standards.freedesktop.org/menu-spec/latest/index.html I don't think that's right, gnome-app-install is an Ubuntu thing. What you mean is we can drop a .menu file into ~/.config/xdg/menus/applications-merged and it'll be automatically linked in. We can do this in wineprefixcreate (or when the first menu entry is created). > 2) Create some Wine .desktop files that can go > in /usr/share/applications that will be readable by this menu entry. > These will be for system-wide Wine apps that are common to all users. > This will include Wine's own apps (like the configuration tool and the > uninstaller) as well as packages which depend on Wine (such as > Winetools). If we're going to create our own submenu to map the start menu we may as well put stuff like winecfg and the control panel there. No need to merge them into the main menu (where would they go, anyway?) > 3.) The menu specification can also point to a new location in the local > user's .wine directory, probably something like ~/.wine/menu. The winemenubuilder program is a winelib app so it'd be better to have it in, eg "~/.wine/drive_c/windows/start menu" > Here we'll have the user-specific .desktop files that link to the > Windows applications that user has installed. Once we figure out how to > make Wine build a start menu and translate the shortcuts into .desktop > files, they can be created there. It already does/can do, see winemenubuilder. We basically need to ensure it still works (probably hasn't actually worked properly for ages) and then merge the start menu directory in using the <LegacyMenuDirs> element. > These files can be kept up to date > (such as when a user installs a new windows application) by the > wineserver program. What will then tell Gnome to update the > applications menu (since new .desktop files will have been created) I'm > not sure yet. Not quite. The wineserver is a low level thing. Menu entries are created on the fly by the shell linker interface. GNOME monitors the menu directories/files so when they change it can reload the definitions (in theory, in practice this is broke on quite a few distros). > 4.) Once we get all that working, then we can start playing around with > icons. This should be fairly easy to translate across platforms. It > would be nice to have icons that Windows apps install available > centrally - this could perhaps be another dekstop integration task on > the Wine todo list. Already done. Again, observe that programs can place launchers onto the desktop (which you can then drag to the panel etc). thanks -mike

1 0

Borland C++ Buildeer under Wine
by Andrew Neil Ramage 13 Mar '05

13 Mar '05

Below is the last three lines of error messages printed when I tried to run Borland C++ Builder under wine. (There were pages and pages of error messages after I hit Ctrl-C in the terminal I had started BCB.EXE from.) Is this a known bug in Wine ? err:syslevel:_EnterSysLevel (0x40797840, level 2): Holding 0x4083ccc0, level 3. Expect deadlock! err:syslevel:_CheckNotSysLevel Holding lock 0x4083ccc0 level 3 err:seh:setup_exception stack overflow 176 bytes in thread 0009 eip 004078d5 esp 405b0f50 stack 0x405b0000-0x406b0000 [andrew@zeus BIN]$ -- Andrew [hackcoughsniffle] Internal Virus Database corrupt

1 0

Re: [Wine]libwine-alsa, etc. still relevant?
by Scott Ritchie 13 Mar '05

13 Mar '05

On Sun, 2005-03-13 at 11:01 +0200, David Baron wrote: > This came up before when debian upgrade wanted to remove these because of > their being the previous version. Now all the version numbers are consistant. > Deborphan lists them as orphans--no longer used! > > So ... are all these provided in the "main" wine library and these packages > actually orphans? If so, why are they still around? If not, what is going on? > > Packages are from the wine.sourceforge.net locations instucted on the winehq > site. > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-users They're merged into the wine package in the winehq debs, since Wine is expecting them to be there anyway. Thanks, Scott Ritchie

1 0

Re: Warcraft 3 - "no program start menu found"
by Juan Lang 13 Mar '05

13 Mar '05

--- Tony Lambregts <tony.lambregts(a)gmail.com> wrote: > I really appreciate you looking at this. Thanks for the patch. No worries, thanks for finding it. That'd been lurking for months, and it was my bug. Glad to flush it out. --Juan __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

dlls/dbghelp/elf_module.c, possible problem?
by Gerald Pfeifer 13 Mar '05

13 Mar '05

Eric et al, the recent changes to dlls/dbghepl/elf_module.c have triggered the following compiler warning (using GCC 3.3) elf_module.c:1167: warning: passing arg 2 of pointer to function makes integer from pointer without a cast Would you mind having a look? Thanks, Gerald

1 0

Re: winetest, winrash and new volunteers
by Steven Edwards 13 Mar '05

13 Mar '05

Hi, --- Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: > I can give devel access to winrash cvs to anyone that wants it. I'm too busy > to work on this stuff myself these days. Is there some good documentation on how winrash and winetest work and communicate with the server? I am interested it in using it as part of the ReactOS build system. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Wine Start Menu in the Desktop Applications Menu
by Scott Ritchie 13 Mar '05

13 Mar '05

One of the most commonly requested features for Wine is for Wine to be aware of applications that put themselves into the Windows Start menu. We've talked about it on the Wine lists before, but there have been some difficulties. The first is that we don't yet understand how to read Windows shortcut files and interpret them: this can probably be overcome with some work. However, there are some other barriers to entry that are now turning around thanks to the Freedesktop.org specs. Here, I propose a short plan of action for getting Wine applications into the Applications menu. Some of these need to be done at the distribution level and some need to be done within Wine. When we have it working nice and smoothly we can submit whatever changes we made to freedesktop.org as well if they need to become a cross-distribution standard. Here's how I see we can do this in Ubuntu: 1) Create a new Menu entry in the .menu file at /usr/share/gnome-app-install/applications.menu This one will be named "Windows Applications" and will need to point to two locations for .desktop files: system-wide ones, and user-specific ones. Instructions for how to do this are here: http://standards.freedesktop.org/menu-spec/latest/index.html 2) Create some Wine .desktop files that can go in /usr/share/applications that will be readable by this menu entry. These will be for system-wide Wine apps that are common to all users. This will include Wine's own apps (like the configuration tool and the uninstaller) as well as packages which depend on Wine (such as Winetools). 1 and 2 will get us some nice launch icons for the important pieces of Wine that most users aren't yet aware of (such as the new uninstaller and winecfg tools). Combined with Wine's ability to make desktop launcher icons when a program says to install an icon on the desktop, this should be a fairly good start at making Wine console-free. 3.) The menu specification can also point to a new location in the local user's .wine directory, probably something like ~/.wine/menu. Here we'll have the user-specific .desktop files that link to the Windows applications that user has installed. Once we figure out how to make Wine build a start menu and translate the shortcuts into .desktop files, they can be created there. These files can be kept up to date (such as when a user installs a new windows application) by the wineserver program. What will then tell Gnome to update the applications menu (since new .desktop files will have been created) I'm not sure yet. 4.) Once we get all that working, then we can start playing around with icons. This should be fairly easy to translate across platforms. It would be nice to have icons that Windows apps install available centrally - this could perhaps be another dekstop integration task on the Wine todo list. 5.) Different architecture issues. One of these days a working amd64 version of the Wine packages will be available (perhaps whenever I manage to afford a new amd64 computer). It's entirely doable to make it work transparently, once the upstream quirks in compiling Wine on 64 bit get worked out. We can also install 32 bit libraries (so we can run 32 bit windows programs) in a way similar to what we do with Open Office. The PowerPC version of the packages, however, is another issue. Obviously, we can't make Wine work with i386-compiled apps on PPC, however we can make it work with Winelib ones. If I ever finish packaging up eMule after getting it to compile in Winelib, a PPC Wine package version could put the .desktop files into the same place as Winetools goes, and then put eMule right there alongside it on PPC. Alternatively, on PPC we could just not use the new Windows Applications submenu altogether, and instead put Winelib apps like eMule in a normal place like Applications->Internet. I still have no idea exactly who is going to do which part of this work, or when, but it all seems like the right way forward to me. Comment is very appreciated. Thanks, Scott Ritchie

2 1

Re: Warcraft 3 - "no program start menu found"
by Juan Lang 13 Mar '05

13 Mar '05

> I am beginning to I suspect it should really go in > dlls/shell32/shellpath.c It is. I think I see where the bug is, and I'm working on it. I should have a patch sometime this weekend, maybe later tonight. --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

winetest, winrash and new volunteers
by Paul Vriens 13 Mar '05

13 Mar '05

Hi, as can be seen from the test.winehq.org site the number of test-runs dramatically dropped. Apart from the fact that there were problems with the automated download of new tests by winrash: http://www.winehq.org/hypermail/wine-devel/2005/03/0373.html winetest will not run but bail out because there is no visible desktop. 3 of the 5 (!) tests that are now there, where done by me. Where in a 'normal' case we should already have dozens. I don't want to go into a discussion about the fact that 'running as a service' and 'on a visible desktop' can/cannot live together properly. Or why we should have 'visible' tests or not. I just want to have as much tests run as possible. I mean that was the whole idea behind it right? An approach should be decided upon: - Have (again) volunteers who run the winetest manually/interactively - Use winrash and have every test decide whether it needs interactivity - 'Fix' winrash so tests run, maybe semi-automated, on a visible desktop - .... An approach for the last is to have winrash fill in one of the 'run' keys (as it does on win98 already during install). I will be/stay a volunteer for the first approach until we decide what to do. Cheers, Paul.

3 2

Re: [ARTWORK] icon: "My Computer"
by egore 13 Mar '05

13 Mar '05

Am Samstag, den 12.03.2005, 16:34 -0700 schrieb Brian Vincent: > On Sun, 13 Mar 2005 00:08:04 +0100, egore <egore(a)gmx.de> wrote: > > Am Samstag, den 12.03.2005, 23:02 +0100 schrieb egore: > > > Hi list, > > > > > > I drew a simple icon that COULD be used as a replacement for the current > > > one. I don't know if anyone of you likes it, so please tell me what you > > > think. Tell me if you like it, if you hate if, what could be done > > > better, etc. > > > > > > The icon can be found in different sizes (and in a scalable format) at > > > http://www.egore911.de/vype/wine/ > > I really like the 128x128 and 64x64. I think they're great. The > 32x32 version is hard to distinguish. I think the only reason is > because the outline of the computer needs to be in black and maybe the > monitor a little smaller. Also, I think we need a 16x16 version more > than a 128x128, so it needs to scale small. You're right. I added it in 16x16 to the website. The problem is that the icon is not recognizable at that size. I will check how to tweak them to scale them down (and both ideas you pointed out sound good to me). > > Ultimately what needs to happen to use them is to insert them as a > resource and use the Wine Resource Compiler on them. I think we have > a bunch of tools that do this, but I'm not sure. If you read the > Developers Guide it will explain this process. However - don't feel > like you need to go that far if you're not comfortable with it. I think integration of the icons is a bit early. I think some more wine-devel readers (Alexandre for example) should say if they like them or not and what can be done better. As soon as we can agree on an icon, I will look at the guide and try to use the "bunch of tools". > At > this point we really need some good artists to clean some of our ugly > crud up. I will see what I can do :D > For instance, the new winecfg tool has a decent logo on the > "About" tab. However it could be a lot nicer - drop shadow inserted > or something. I think the logo is much better than the icons from the picker. But I will look at it later. > > Good work! Thanks :D Chris

2 1

Re: Theming for Wine via the registry
by Oliver Stieber 12 Mar '05

12 Mar '05

> > Ah, that's different. That'd actually require using > Gtk/Qt which we cannot > do, the best we can get is to look like them. > What's the problem, licensing, integration or thread-safety (I know QT isn't thread safe) > To be fully accessible we'd need to implement the > OLE Accessibility > framework and bridge it to AT-SPI or something > similar. > I may have a look at that too, it would be useful if QT/GTK could use some of the existing Windows accessibility software. I was thinking about going on a fund finding mission, or at least trying to find someone who wants to pay for an initial integration, it shouldn't be too hard as most companies are no where near their requirements. Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1

Re: [OLE #82] Implement VT_BYREF | VT_BSTR marshalling
by Rob Shearman 12 Mar '05

12 Mar '05

Mike Hearn wrote: >Implement VT_BYREF | VT_BSTR marshalling > > Hi Mike, I've got a bigger patch in my tree at the moment that has your patch plus VT_BYREF|VT_BSTR unmarshaling, plus some other types. The thing now blocking InstallShield seems to be a nasty deadlock in the COM code that I haven't figured out yet. Rob

2 1

Re: wine/ misc/registry.c documentation/samples/config
by Mike Hearn 12 Mar '05

12 Mar '05

Hi Alexandre, What is the thinking behind this patch? If we don't load the Windows registry on startup where should it be loaded? Will this code re-appear at any point in the future? A significant number of users still expect to be able to point Wine at an actual Windows install despite what we recommend. thanks -mike On Fri, 11 Mar 2005 07:10:25 -0600, Alexandre Julliard wrote: > ChangeSet ID: 16565 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/03/11 07:10:25 > > Modified files: > misc : registry.c > documentation/samples: config > > Log message: > Get rid of the Windows registry loading on startup, this needs to be > done differently. > > Patch: http://cvs.winehq.org/patch.py?id=16565 > > Old revision New revision Changes Path > 1.149 1.150 +6 -1498 wine/misc/registry.c > 1.73 1.74 +0 -2 wine/documentation/samples/config

4 5

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