wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Running Delphi old version
by Marcelo Welter 20 May '02

20 May '02

Hello Running Delphi Old version 3 i have the error: err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. This error is visible if i run with Desktop=N Managed=N or Y I see a splash screen of delphi before close completly if i run with Desktop=800x600 I see a "stack Overflow" error in the desktop window. I click in the OK button of many error windows and after this delphi open, but all actions and buttons are locked The recent version 6 running ok. I need run this old version to port some applications to new version, and i want kick windows of my machine... :) Well if anybody have any idea please, send me... Thanks Marcelo

1 0

winehq.com or winehq.org?
by Andriy Palamarchuk 20 May '02

20 May '02

Jeremy, reading your comments regarding fixing bug 639 I was kind of surprised that you asked to use '.org' domain. I personally always thought that official site name is winehq.com. What is the story behind using 2 separate names? Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

5 8

Requested Change to the build system
by Steven Edwards 20 May '02

20 May '02

Hola and Thanks for everything so far in getting the Mingw port rolling. Doing my work on getting shlwapi.dll built I noticed the missing imports from user32 wvsnprintfA@16 and wvsnprintfW@16 in libuser32.a. I was going to submit a patch to the mingw developers for the Win32api package that updates the libuser32.a and I am still planning on doing that but I think a more self-contained solution would be better. In the ReactOS tree we have a "make implib" rule to generate all of the import Libs for our shared libs. This way we are not dependant on the mingw win32api. I think the wine tree needs to do something similer. Once this is done we can go ahead and build the import libs for ntdll, msvcrt and User32 that are needed for the wine dlls. The command line is something like this dlltool --as=as --dllname user32.dll --def user32.spec.def --output-lib libuser32.a The only real problem isnt really a problem but we just wouldn't catch it in the build processes. If WINES libuser32.a exported a non-win32 function that we shouldn't Use anyway and another dll imported that function (see comctl32) like GetSysColorPen (see wine/windows/syscolor.c line 388) The build would still work and we wouldn't catch it untill someone tries to use comctl32.dll without wines user32.dll. I still think the change would be for the better and request your comments. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

3 3

Links on wine-{devel, patches} archives are not excactly broken.
by Vassilis Virvilis 20 May '02

20 May '02

Halo, Since there is a lot of talk about switching winehq.com to winehq.org I thought I mention something that bothers me in case some kind of reorganization takes place. 1) No newsgroup gateway anymore. What a pitty! But anyway one can always read from the archives, which brings us to the second observation. 2)This is a typical link in the monhtly index by date http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/2002-05/… And here is the same article but linked through the previous article http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/2002-05/… Notice the data vs Date thing that breaks my browser (mozilla) visited links (All links are not visited in the main index page). Thanks in advance. .Bill

1 0

Re: Bugzilla: more privileges?
by Andriy Palamarchuk 20 May '02

20 May '02

--- Dustin Navea <speeddymon(a)yahoo.com> wrote: > Could someone that has the ability to modify > priviledges please give me some? Done. Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

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

Patch for dinput keyboard
by arjen＠blehq.org 19 May '02

19 May '02

This 'beautiful' patch I wrote for fixing dinput was silently ignored. Can someone comment about it? here is a link to it: http://www.winehq.com/hypermail/wine-patches/2002/05/0047.html Thank you

3 5

Re: Mingw devel stuff Part2
by Steven Edwards 19 May '02

19 May '02

After that patch I am also able to compile these dlls Comcat.dll Crtdll.dll Msisys.ocx Netapi32.dll Riched32.dll Serialui.dll Twain_32.dll Wintrust.dll I know that some of them are mostly stubs but its still a good start. I understand WINEs crtdll just forwards call to msvcrt.dll but will this also work on a Windows Target? I was under the impression this Wouldn't work due to crtdll not being thread safe. Or will this only Work on *NIX hosts using wines MSVCRT? Its not a big deal to the ReactOS project as we already have crtdll and msvcrt we maintain but it would always be nice to have one less thing to keep up. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

process.c problem update
by Dustin Navea 18 May '02

18 May '02

Ok, I finally implemented the right checks in process.c to get the Unreal Tournament-based installers working properly, now all I have to do is make the diff and submit it. The code is very ugly and I was wondering if someone would volunteer to clean it up, since I'm not sure if it will be committed in it's current state... Also, will be included a fix for Blizzard Installers that "cant find program start menu". Seems there is a missing registry entry... If you are willing to clean up my messy code, please email me privately and let me know. -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Mingw devel stuff Part2
by Steven Edwards 18 May '02

18 May '02

Sorry about that I hit the send button to soon. OK when I try build shlwapi.dll I'm getting this Administrator@LAPTOP /cygdrive/d/src/winehq/wine/dlls/shlwapi $ make dllwrap --add-stdcall-alias --def shlwapi.spec.def --implib shlwapi.a -o shlwapi .dll ordinal.o path.o reg.o regstream.o shlwapi_main.o string.o url.o shlwa pi.dll.dbg.o -L../../dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -L../../library -lwine -L../../ole -lwine_uuid -L../../unicode -lwine_unicode -lm Warning: resolving ___wine_dbgstr_guid by linking to __imp____wine_dbgstr_guid ( auto-import) Warning: resolving ___wine_dbgstr_an by linking to __imp____wine_dbgstr_an (auto -import) Warning: resolving ___wine_dbgstr_wn by linking to __imp____wine_dbgstr_wn (auto -import) ordinal.o(.text+0x52d6):ordinal.c: undefined reference to `wctype_table' ordinal.o(.text+0x52eb):ordinal.c: undefined reference to `wctype_table' path.o(.text+0x74d6):path.c: undefined reference to `casemap_lower' path.o(.text+0x74eb):path.c: undefined reference to `casemap_lower' path.o(.text+0x751a):path.c: undefined reference to `casemap_upper' path.o(.text+0x752f):path.c: undefined reference to `casemap_upper' path.o(.text+0x7752):path.c: undefined reference to `wctype_table' path.o(.text+0x7767):path.c: undefined reference to `wctype_table' string.o(.text+0x1d2d):string.c: undefined reference to `wvsnprintfA@16' string.o(.text+0x1d61):string.c: undefined reference to `wvsnprintfW@16' string.o(.text+0x1d8e):string.c: undefined reference to `casemap_upper' string.o(.text+0x1da3):string.c: undefined reference to `casemap_upper' url.o(.text+0x4426):url.c: undefined reference to `wctype_table' url.o(.text+0x443b):url.c: undefined reference to `wctype_table' fu000001.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000002.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000004.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000005.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000006.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000007.o(.idata$3+0xc): more undefined references to `libwine_a_iname' follow nmth000000.o(.idata$4+0x0): undefined reference to `_nm____wine_dbgstr_guid' nmth000003.o(.idata$4+0x0): undefined reference to `_nm____wine_dbgstr_an' nmth000009.o(.idata$4+0x0): undefined reference to `_nm____wine_dbgstr_wn' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [shlwapi.dll] Error 1 "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

2 3

opengl rendering to the wrong window
by Ryan Stallings 18 May '02

18 May '02

Hello, I am trying to get the Neverwinter Nights Model viewer (http://www.bioware.com/games/neverwinter_nights/other_multimedia/model_view…) working under wine. The menus etc of the model viewer come up correctly, but no rendering can be seen in the render window. Through some investigation I determined that the model was being rendered, just in the wrong window. I moved the window out of the way by a few pixels and saw the model was being rendered to what looks like the main window underneath the menu. Here is a screen shot that shows what I mean..... http://nwwine.beergeek.net/shots/nw_offset.jpg The black square is the windows shifted and the blue background is the glClearColor of the rendering window. As you can see the model is under the window :( Now if I move the window way offscreen and add an offset to the glViewport call I can get the model to render in the correct place, but this is obviously not the right solution. What could be causing it to be rendered in the wrong window? The render window has a hwnd =1003e and a drawable client/whole = 0x4000064/0x4000063 and the first couple of time through wglMakeCurrent the drawable that comes back from the hdc that is passed (requested from 1003e) is 0x4000064 which seems right, but I think this is some sort of test renderings offscreen before the application comes up. Later in the logs this is not true. GetDCEx is called with 1003e, but it returns a hdc that has a different drawable associated with it (the one for the root window I think). But even if I try to for the drawable to 0x4000064 is does not render in to the correct window (it does not render at all). Does anybody have any direction to point me in? Or is there any information that I could provide to make the situation more clear? Thanks! ryan

2 1

nasty NTDLL_vsnwprintf bug?!?
by John K. Hohm 18 May '02

18 May '02

My heap corruption problem turned out to be a bug in swprintf (well, really in NTDLL_vsnwprintf), I think. I tried formatting like this: WCHAR keyname[21] = { 'C', 'o', 'm', 'p', 'o', 'n', 'e', 'n', 't', ' ', 'C', 'a', 't', 'e', 'g', 'o', 'r', 'i', 'e', 's', 0 }; WCHAR fmt[4] = { '%', 'l', 'X', 0 }; swprintf(This->xlcid, fmt, lcid); My poor little WCHAR xlcid[9] member of This was seriously overflowed by the string L"409Component Categories". The following patch fixes what appears to be a format reading bug in NTDLL_vsnwprintf. I didn't just send it to wine-patches because it's not my area and it seems unlikely such a bad bug could hang around in such a function. Then again, I don't see many uses of swprintf in the source; should I be using something better for sprintf's of WCHAR's? --- dlls/ntdll/wcstring.c.~1.15.~ Thu May 16 19:59:27 2002 +++ dlls/ntdll/wcstring.c Fri May 17 23:09:21 2002 @@ -451,10 +451,7 @@ } if (*iter == (WCHAR)L'h' || *iter == (WCHAR)L'l') - { *fmta++ = *iter++; - *fmta++ = *iter++; - } switch (*iter) {

1 0

Weird parameters with LVM_GETSUBITEMRECT
by Paul Rupe 17 May '02

17 May '02

A recent change to dlls/comctl32/listview.c implemented GetSubItemRect, but this causes Xnews to hang when selecting a newsgroup from the list. I don't think the change itself is at fault, but it may have uncovered a bug elsewhere. The app gets a message LVM_GETSUBITEMRECT (4152) with the following parameters: wParam: 1078422692 (0x40476ca4) lParam: 1078422612 (0x40476c54) wParam should be a small integer (an index into the listview items) and lParam is a pointer to a RECT: *(LPRECT)lParam: {left = 2, top = 1079544291, right = 28246089, bottom = 1079843718} or {left = 0x2, top = 0x405889e3, right = 0x1af0049, bottom = 0x405d1b86} lParam->left is reasonable, but lParam->top should be a small index. Note that wParam, lParam, and lParam->top are fairly close numerically. The function LISTVIEW_GetSubItemRect then tries to loop from 0 to that huge number, causing the hang. I put a sanity check inside that function to stop it from going past GETITEMCOUNT and that works, but I want to see if I can fix it the right way. -- Paul Rupe "She smiled, in the end." p r u p e @ m y r e a l b o x . c o m | Oppose government police-ware on your PC! | Stop the Consumer Broadband and Digital Television Promotion Act! | <http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html> --

1 0

Re: fixme:win32:PeekNamedPipe
by Andriy Palamarchuk 17 May '02

17 May '02

I just came across bugzilla entry about this issue - bug 297: http://wine.codeweavers.com/bugs/show_bug.cgi?id=297 If anybody starts to work on the bug, please take this bug and keep it updated. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

2 1

Mingw Port Information and Questions
by Steven Edwards 17 May '02

17 May '02

OK so we the latest changes I do need to build libwine.dll right? I can if I link it to msvcrt.a but ig I don't I get the following Administrator@LAPTOP /cygdrive/d/src/winehq/wine/library $ make dllwrap --add-stdcall-alias --export-all --implib libwine.a -o libwine.dll debug .o errno.o ldt.o loader.o port.o dllwrap: no export definition file provided dllwrap: creating one, but that may not be what you want debug.o(.text+0x8d4):debug.c: undefined reference to `_imp___iob' loader.o(.text+0x4c4):loader.c: undefined reference to `_assert' loader.o(.text+0x614):loader.c: undefined reference to `_assert' port.o(.text+0x4):port.c: undefined reference to `_errno' port.o(.text+0x30):port.c: undefined reference to `_errno' port.o(.text+0x48):port.c: undefined reference to `_errno' port.o(.text+0x60):port.c: undefined reference to `_errno' port.o(.text+0x78):port.c: undefined reference to `_errno' port.o(.text+0x90):port.c: more undefined references to `_errno' follow collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [libwine.dll] Error 1 Also when I try to build shlwapi.dll I get this

1 0

Problem in scheduler/process.c
by Dustin Navea 17 May '02

17 May '02

ok, so I have found the cause of the problem in scheduler/process.c that is making ut-based installers not work. the problem is the code from line 450 to line 461 inclusive. in all programs, PROCESS_InitWine is called from int main in miscemu/main.c, then open_winelib_app is called from PROCESS_InitWine (always) where things go wrong... in a normal program, 1 of 2 things (im not sure which though) happens... 1) line 451 evaluates to false so that section is skipped and then line 461 is also evaluated to false, so it is also skipped, so open_winelib_app returns either null or " " (not sure of the difference) -or- 2) line 451 evaluates to true, and then 457 also evaluates to true, so open_winelib_app returns NULL. with the ut-based installer that is the case, but the Setup.exe that is on the root of the cd acts differently... 1) 451 evaluates to false and then 461 evaluates to true, causing wine to attempt to load the real installer (called by the one in the root of the cd) as a .so, which doesn't work. -or- 2) 451 evaluates to true and 457 evaluates to false, so it goes on to 461, which evaluates to true... with winelib apps the same thing happens as with the "root-of-cd" installer except that the .so file does exist and so it gets loaded... so, i think what needs to be done is a check in PROCESS_InitWine for the kind of binary (windows or winelib). and if it is a winelib binary, then run call open_winelib_app, otherwise proceed with normal loading... probably the easiest way to do this would be like this line 491-494 if (argv[0] != 'wine') { if (open_winelib_app( app_argv )) goto found; } that way you could probably completely remove lines 450-459 which are in open_winelib_app, since all it does is check to make sure argv[0] doesn't equal wine... i would try this method out and submit it, but i won't be back at home until tonight, so i can't make any diff's. if someone wants to give it a go and let us know if it works, please give me credit for the _idea_. hopefully this solves some other problems too... comments appreciated. -Dustin __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

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