wine-devel

wine-devel@winehq.org

6 participants
84404 discussions

Re: change email
by Alexandre Julliard 19 May '02

19 May '02

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > changed my email address at important "notification" locations in wine. > The supposedly eternal email a.mohr(a)mailto.de has bitten the dust ages > ago already. That's why you should never put an email address in error messages. Not only because addresses change, but your code may be used in other products where reporting problems to you is not the appropriate thing to do. Just say "please report this" and let users figure out where to report it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PATCH] winedefault.reg
by Dustin Navea 19 May '02

19 May '02

--- Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > >>>>> "Dustin" == Dustin Navea > <speeddymon(a)yahoo.com> writes: > > Dustin> ok, after the patch submission that adds > Serial0=COM1 to the > Dustin> sources, here is the one that adds it to > the default wine > Dustin> registry... > > Dustin> -Dustin > > Dustin> hopefully alexandre commits all 3 of the > patches posted > Dustin> today.... ;)] > > Dustin> if he doesn't, i would like to know what > needs to be done to > Dustin> each to get it committed... > > Are you sure you really attached the patch? I see > nothing... > > Bye Oops, guess attaching it would help, wouldn't it? brb -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Re: [PATCH] misc/registry.c
by Dustin Navea 19 May '02

19 May '02

--- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > Then something must be very wrong with registry > import of NT based systems. > Could you investigate why wineinstall/wine fails to > pick up the NT registry ? > sure...actualy i did some investigation on this a few weeks ago and discovered that the only time that real-windows registries are loaded is when the path to your true windows directory is in wine's windows path... i only keep my fake-windows directory in there since linux can only read from a ntfs partition. Now I could put the real-windows directory in the wine sources, but that would cause a problem for users that don't use the same names as me...my windows partition is mounted at /windows, but the default (at least for mandrake) is something else... so that really wouldn't be feasible unless someone else wants to put some code in there to search the entire heirarchy for system32/config/system and even then, on mandrake, only root can read from the winnt partition (if you dont modify the priveleges) -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Send that last email to /dev/null
by Steven Edwards 19 May '02

19 May '02

I see wvsnprintf16 in user32 is marked (Not a Windows API) also. So we have (user32) GetSysColorPen/wvsnprintf and (ntdll) wine_get_unix_file_name That need to be fixed for mingw. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

RE: Native User32
by Steven Edwards 19 May '02

19 May '02

See my other email about build system changes. Other wine dlls are dependant on wine's user such as comctl32 for The GetSysColorPen function that is not part of the Win32api. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

Re: [PATCH] misc/registry.c
by Andreas Mohr 19 May '02

19 May '02

On Sun, May 19, 2002 at 09:18:42AM -0700, Dustin Navea wrote: > ok, here is the needed patch to get Blizzard's > installers to not complain _ever_ about not being able > to find program start menu... this also adds in a reg > key for HARDWARE\\DEVICEMAP\\SerialComm > "Serial0"=""COM1" > > I think that the code to write to HKLM may be slightly > broken though, as I couldn't get any of the hklm > entries in misc/registry.c to be written, except for > the ComputerName one... I dunno, someone wanna have a > look at it? I'm creating a bug for it soon as i send > this out... Yep, it's pretty wrong. RTFM would definitely have helped. winedefault.reg has had the start menu key for decades. (http://www.winehq.com/Trouble/ also mentions it) Thanks for the Serial0 fix, though ! (although that one probably should go to winedefault.reg, too...) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

2 3

Re: [PATCH] misc/registry.c
by Dustin Navea 19 May '02

19 May '02

--- J�rgen_Schmied <juergenschmied(a)lycos.de> wrote: > Where from do you know windows is in c:\windows on > every computer??? > Should't it in duty of shell32 to manipulate the > ShellFolder entrys? > > Think it's not as simple as this... > > juergen > the fact that windows may not always be in C:\Windows is true, the reason i put it there is because that is the default windows directory i.e. wine creates it if it isn't there... Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 1

Re: [PATCH] misc/registry.c
by Jürgen Schmied 19 May '02

19 May '02

Where from do you know windows is in c:\windows on every computer??? Should't it in duty of shell32 to manipulate the ShellFolder entrys? Think it's not as simple as this... juergen > I think that the code to write to HKLM may be slightly > broken though, as I couldn't get any of the hklm > entries in misc/registry.c to be written, except for > the ComputerName one... I dunno, someone wanna have a > look at it? I'm creating a bug for it soon as i send > this out... --- juergen.schmied(a)debitel.net

1 0

Note to Andreas Mohr
by Dustin Navea 19 May '02

19 May '02

Hey, in misc/registry.c I saw you had a note about something not being implemented (in a fixme output) and it said to email you at a.mohr(a)mailto.de or something like that... not sure if you still use that email, but i thought i would let you know in case you didn't... -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

2 1

[Patch] scheduler/process.c
by Dustin Navea 19 May '02

19 May '02

Ok, here is a quick rundown of the problem... all programs were being passed to open_winelib_app by PROCESS_InitWine. Once inside open_winelib_app, there was a sanity check for if argv[0] was equal to wine which if it was and you were trying to run a winelib app, then it would bail out, and if it wasn't it would run the program if it was wine and you weren't trying to run a winelib app then it would run it... the problem was that with /mnt/cdrom/Setup.exe not being the real installer for Unreal Tournament (being just a caller for the real installer), argv[0] would equal wine on the first run though (/mnt/cdrom/Setup.exe), but it would equal /usr/local/bin/wine on the 2nd run through (/mnt/cdrom/System/Setup.exe), which doesn't equal "wine", so it would try to open the app as a winelib app. I moved that incorrect code from open_winelib_app to PROCESS_InitWine and modified it so that it would change "/usr/local/bin/wine" to "wine" but otherwise leave it alone... the code is ugly, but it works, if someone want's to clean it up, feel free to do so, just give me credit for the original submission... -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com Author: Dustin Navea ChangeLog: adds the necessary check to PROCESS_InitWine, so that we no longer pass _every_ application to open_winelib_app (saving some headaches with weird windows binaries) License: ALL Permissions: you may use this to teach yourself c, and may modify the code in this diff, only to clean it up. you must maintain this notice and give credit for the original submission in your cleaned up submission. ===================================================================================== --- scheduler/process.c Sat May 18 20:23:26 2002 +++ scheduler/process.c.new Sat May 18 20:18:55 2002 @@ -447,21 +447,12 @@ } else { - const char *argv0 = main_exe_name; - if (!*argv0) - { - /* if argv[0] is "wine", don't try to load anything */ - argv0 = argv[0]; - if (!(name = strrchr( argv0, '/' ))) name = argv0; - else name++; - if (!strcmp( name, "wine" )) return NULL; - } - /* now try argv[0] with ".so" appended */ if ((tmp = HeapAlloc( GetProcessHeap(), 0, strlen(argv0) + 4 ))) { strcpy( tmp, argv0 ); strcat( tmp, ".so" ); + name = argv0; /* search in PATH only if there was no '/' in argv[0] */ ret = wine_dll_load_main_exe( tmp, (name == argv0), errStr, sizeof(errStr) ); if (!ret && !argv[1]) @@ -485,11 +476,31 @@ void PROCESS_InitWine( int argc, char *argv[], LPSTR win16_exe_name, HANDLE *win16_exe_file ) { DWORD stack_size = 0; + const char *name; /* Initialize everything */ if (!process_init( argv )) exit(1); - if (open_winelib_app( app_argv )) goto found; /* try to open argv[0] as a winelib app */ + /* these next 2 if's check the name of the wine executable being run for + compatibility with weird apps */ + if (!(name = strrchr( argv[0], '/' ))) name = argv[0]; + else + { + name = strrchr( argv[0], '/' ); + name = strstr( name, "wine" ); + } + if (!(argv0 = strrchr( argv[0], '/' ))) argv0 = argv[0]; + else + { + argv0 = strrchr( argv[0], '/' ); + argv0 = strstr( argv0, "wine" ); + } + + if ((strcmp( argv0, "wine" )) && (strcmp( name, "wine" ))) + { + /* try to open argv[0] as a winelib app */ + if (open_winelib_app( app_argv )) goto found; + } app_argv++; /* remove argv[0] (wine itself) */ app_argc--;

1 0

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