- wine-devel - winehq.org

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

Re: Fix for focus loops
by Jukka Heinonen 17 May '02

17 May '02

On Tue, May 07, 2002, Alexandre Julliard wrote: > I've been working on this too, and I found that the locally active > model seems to work better with most window managers, even though it's > not 100% correct per the spec. Here's the patch I have, please give it > a try and let me know how it works for you. If your patch is used in globally active mode (Wine config file has "UseTakeFocus" = "Y"), focus loop problem is fixed. However, if I try locally active mode, Wine still enters focus loop. Some comments about the patch and Wine focus handling: - Timestamp used in X11DRV_SetFocus is wrong when focus has been gained either due to WM_TAKE_FOCUS or due to FocusIn. - Routine X11DRV_SetFocus may fail to set focus because focus might have already been passed to another X11 window. In unmanaged mode this is fatal: override_redirect windows receive neither WM_TAKE_FOCUS nor FocusIn and if Wine believes that a window already has focus it won't call X11DRV_SetFocus even when the window receives mouse clicks. - If X11DRV_SetFocus fails, Wine routine that triggered this call (SetForegroundWindow, SetActiveWindow, SetFocus, etc) should also fail. This is what NT5.0 does according to docs, by the way. This would make it easy to see which window really has focus. - It is likely that last_focus will be wrong if routine X11DRV_SetFocus fails as described above. - All Wine windows using override_redirect break ICCCM. This includes all windows in unmanaged mode. In general, it is not possible for override_redirect windows to gain input focus without confusing focus handling of window managers. There are two exceptions to this generalization which likely apply to full-screen applications and menus. - In locally active model, transferring focus from top-level window to active dialog window requires timestamp CurrentTime which breaks ICCCM compliance. This can break window manager focus handling in some cases. This is likely not very big an issue, but I believe that everything that breaks standards should be properly commented. - One not directly focus relared problem is that some window managers always put override_redirect windows on top of managed windows. And when you run some applications in managed mode, Wine creates a full screen override_redirect window which has managed dialog window... Looking at this list makes me believe that fixing Wine focus handling should be assigned much higher priority than it has been so far. -- Jukka Heinonen <http://www.iki.fi/jhei/>

4 6

Problem after update
by Marcelo Welter 17 May '02

17 May '02

Hello I make cvs update -RdP configure make depend make ./snmpapi.spec:6: Expected name, id, length or ordinal make[2]: *** [snmpapi.spec.c] Error 1 make[2]: Leaving directory `/home/marcelo/wine/cvs/wine/dlls/snmpapi' make[1]: *** [snmpapi/snmpapi.dll.so] Error 2 make[1]: Leaving directory `/home/marcelo/wine/cvs/wine/dlls' make: *** [dlls] Error 2 what happen? the syntax of cvs that i use are correct...? Thanks Marcelo

3 2

Component owner for window management/painting
by Andriy Palamarchuk 17 May '02

17 May '02

Any volunteers for handing this kind of problems? Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Re: Patch - check for msghdr.msg_control on Sparc-Solaris
by Warren_Baird＠cimmetry.com 17 May '02

17 May '02

> I think it would be better to do it using a technique similar to how it > is done in scheduler/client.c on line 255: Makes sense to me - it wasn't obvious that msg_control and msg_accrights are always mutually exclusive, which is why I added a separate test... But if we're sure they are always mutally exclusive, this approach makes more sense... Warren

1 0

err:heap:HEAP_ValidateInUseArena
by John K. Hohm 17 May '02

17 May '02

I am implementing a COM object in comcat.dll that allocates itself with HeapAlloc and frees itself on its last Release with HeapFree. I am using it in a simple test program that creates it and releases it, and when the Release happens I get this: err:heap:HEAP_ValidateInUseArena Heap 40340000: in-use arena 40378878 next block has PREV_FREE flag It seems to be saying that I'm freeing an already-free block. I ran the test program with --debugmsg trace+all, and I can see that the only uses of the heap during the lifetime of my object instance are one ntdll.RtlAllocateHeap that returns 40378880, and one ntdll.RtlFreeHeap that gets 40378880 as its third param. The RtlFreeHeap is immediately followed by the err:heap, which then spits out a bunch of heap info. It seems pretty obvious that I'm freeing the block of memory I had just allocated; what else might be causing the err:heap? Here is the interesting section of the trace: 080701d0:trace:ole:COMCAT_ICatInformation_EnumCategories 080701d0:Call ntdll.RtlAllocateHeap(40340000,00000008,00000020) ret=4397c0f3 080701d0:trace:heap:RtlAllocateHeap (40340000,0000000a,00000020): returning 40378880 080701d0:Ret ntdll.RtlAllocateHeap() retval=40378880 ret=4397c0f3 080701d0:trace:ntdll:NTDLL_vsnwprintf (2147483647,L"%lX") 080701d0:Call advapi32.RegOpenKeyExW(80000000,40566ce8 L"Component Categories",00000000,00020019,40378898) ret=4397c170 080701d0:Call ntdll.RtlInitUnicodeString(40566bd8,40566ce8 L"Component Categories") ret=40660189 080701d0:Ret ntdll.RtlInitUnicodeString() retval=0000002a ret=40660189 080701d0:Call ntdll.NtOpenKey(40378898,00020019,40566be0) ret=40660194 080701d0:trace:reg:NtOpenKey (0x80000000,L"Component Categories",20019,0x40378898) 080701d0: open_key( parent=-2147483648, access=00020019, name=L"Component Categories" ) Open key ERROR 080701d0: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 } 080701d0:trace:reg:NtOpenKey <- 0x0000 080701d0:Ret ntdll.NtOpenKey() retval=c0000034 ret=40660194 080701d0:Call ntdll.RtlNtStatusToDosError(c0000034) ret=4066019a 080701d0:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=4066019a 080701d0:Ret advapi32.RegOpenKeyExW() retval=00000002 ret=4397c170 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_AddRef 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_Next 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_Release 080701d0:Call ntdll.RtlFreeHeap(40340000,00000000,40378880) ret=4397be9d 080701d0:err:heap:HEAP_ValidateInUseArena Heap 40340000: in-use arena 40378878 next block has PREV_FREE flag

2 1

Re: wine/ dlls/Makefile.in dlls/avicap32/Makefile. ...
by Dimitrie O. Paun 17 May '02

17 May '02

On May 16, 2002 11:37 pm, Alexandre Julliard wrote: > Log message: > Removed most imports of ntdll since we no longer import Wine internal > functions from there. Yay! I've been advocating putting all the wine-specific stuff in a "helper" dlls (libwine) for soo long now, specifically for the purpose of the "Windows" port. Now, the linking things is still a bit of mistery to me. Let's see: -- libwine is linked with all DLLs using the host's native dynlinking tool -- when a program is loaded, _wine_ loads the required DLLs which in turns gets linked by the OS to libwine. Is that so? To be honest, this is how I *think* it works, I haven't actually gone through the code, but I'm feeling lazy tonight :))) -- Dimi.

2 1

Re: wine/ controls/menu.c dlls/commdlg/cdlg32.c dl ...
by Dimitrie O. Paun 17 May '02

17 May '02

On May 16, 2002 10:55 pm, Alexandre Julliard wrote: > > Log message: > Export the debugging API from libwine instead of ntdll. > Removed debugres_[aw]. I think you need to test for null strings in default_dbgstr_[aw]n, no? Also, the default implementations are there for the mingw port? We normally use the ones from NTDLL_dbgstr_*, right? -- Dimi.

2 1

64bit values in API args...
by Vincent Béron 17 May '02

17 May '02

I have a little problem implementing VerifyVersionInfo{A,W}. Here's the prototype of the function (W): BOOL WINAPI VerifyVersionInfoW( LPOSVERSIONINFOEXW lpVersionInfo, DWORD dwTypeMask, DWORDLONG dwlConditionMask) with DWORDLONG being a 64bit value. Now, how do I translate that in kernel32.spec? The current declaration in kernel32.spec is @ stdcall VerifyVersionInfoW(long long long long) VerifyVersionInfoW with either a try to get a "long long" type (undistinguishable from 2 longs), or by just assuming a virtual fourth argument to get the right total argument size. Now, this seems really fishy. I'm not very familiar with the way a C compiler places arguments either in registers or on the stack, but I'm not sure the way it is currently declared is the best way to do it. I'd prefer to define a new type for use in spec files, meaning a 64bit argument. Comments? BTW, for the moment VerifyVersionInfo seems to be the only place in Wine where the DWORDLONG type is used, but that doesn't mean there are no other unimplemented API using it. Vincent

1 0

Component owner for controls
by Andriy Palamarchuk 17 May '02

17 May '02

Does anybody want to voluteer to take ownership over usual controls? I already have owners for common controls Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

2 1

Open watcom
by Uwe Bonnes 17 May '02

17 May '02

Hallo, today, there was an announce of a 0.0.8 release of open watcom on the linux announce newsgroup: http://www.openwatcom.org ftp://ftp.openwatcom.org/watcom/openwatcom Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Fix to get Unreal Tournament-based installers to work from root of CD
by Alexandre Julliard 17 May '02

17 May '02

Dustin Navea <speeddymon(a)yahoo.com> writes: > Hopefully this doesn't break anything. If it does, I > will attempt to fix the open_winelib_app being called > problem... I may need some help though... The real problem is that for some reason Wine didn't recognize setup.exe as a Window binary. That's what you'll need to fix, your patch is only hiding the problem. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: wine/dlls/winmm mmsystem.c winemm.h
by Michael Stefaniuc 16 May '02

16 May '02

Hello, tested the patch and FreeSolitaire works again. You can close the bug entry. thanks bye michael On Thu, May 16, 2002 at 10:03:17PM +0200, Eric Pouech wrote: > Eric Pouech a écrit : > oops the last hunk of the patch isn't part of the patch > so Alexandre, please use this file instead > > A+ > Name: ps_a2w > ChangeLog: fixed hangs when playing an ASCII resource > License: X11 > GenDate: 2002/05/16 19:48:36 UTC > ModifiedFiles: dlls/winmm/mmsystem.c > AddedFiles: > =================================================================== > RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mmsystem.c,v > retrieving revision 1.52 > diff -u -u -r1.52 mmsystem.c > --- dlls/winmm/mmsystem.c 12 May 2002 03:10:26 -0000 1.52 > +++ dlls/winmm/mmsystem.c 16 May 2002 19:39:46 -0000 > @@ -447,6 +447,7 @@ > waveOutUnprepareHeader(hWave, &waveHdr[1], sizeof(WAVEHDR)); > > errCleanUp: > + TRACE("Done playing='%s' !\n", debugstr_w(wps->pszSound)); > CloseHandle(s.hEvent); > HeapFree(GetProcessHeap(), 0, waveHdr); > HeapFree(GetProcessHeap(), 0, lpWaveFormat); > @@ -463,6 +464,21 @@ > return bRet; > } > > +static BOOL MULTIMEDIA_IsString(DWORD fdwSound, const void* psz) > +{ > + /* SND_RESOURCE is 0x40004 while > + * SND_MEMORY is 0x00004 > + */ > + switch (fdwSound & SND_RESOURCE) > + { > + case SND_RESOURCE: return HIWORD(psz) != 0; /* by name or by ID ? */ > + case SND_MEMORY: return FALSE; > + /* any other case (SND_ALIAS, SND_FILENAME... shall drop into this one) */ > + case 0: return TRUE; > + default: FIXME("WTF\n"); return FALSE; > + } > +} > + > static BOOL MULTIMEDIA_PlaySound(LPCWSTR pszSound, HMODULE hmod, DWORD fdwSound, DWORD search) > { > WINE_PLAYSOUND* wps = NULL; > @@ -515,10 +531,9 @@ > } while (InterlockedCompareExchangePointer((void**)&iData->lpPlaySound, wps, NULL) != NULL); > > if (fdwSound & SND_ASYNC) { > - if (!((fdwSound & SND_MEMORY) || ((fdwSound & SND_RESOURCE) && > - !((DWORD)pszSound >> 16)) || > - !pszSound)) { > - wps->pszSound = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(pszSound)+1) * sizeof(WCHAR) ); > + if (MULTIMEDIA_IsString(fdwSound, pszSound)) > + { > + wps->pszSound = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(pszSound)+1) * sizeof(WCHAR)); > lstrcpyW((LPWSTR)wps->pszSound, pszSound); > } > wps->bLoop = fdwSound & SND_LOOP; > @@ -541,16 +556,13 @@ > { > LPWSTR pszSoundW; > BOOL bSound; > + > + pszSoundW = (MULTIMEDIA_IsString(fdwSound, pszSoundA)) ? > + HEAP_strdupAtoW(GetProcessHeap(), 0, pszSoundA) : (LPWSTR)pszSoundA; > > - if (!((fdwSound & SND_MEMORY) || > - ((fdwSound & SND_RESOURCE) && !((DWORD)pszSoundA >> 16)) || > - !pszSoundA)) { > - pszSoundW = HEAP_strdupAtoW(GetProcessHeap(), 0, pszSoundA); > - bSound = PlaySoundW(pszSoundW, hmod, fdwSound); > - HeapFree(GetProcessHeap(), 0, pszSoundW); > - } else > - bSound = PlaySoundW((LPWSTR)pszSoundA, hmod, fdwSound); > - > + bSound = PlaySoundW(pszSoundW, hmod, fdwSound); > + if ((void*)pszSoundW != (void*)pszSoundA) HeapFree(GetProcessHeap(), 0, pszSoundW); > + > return bSound; > } > > @@ -585,14 +597,12 @@ > LPWSTR pszSoundW; > BOOL bSound; > > - if (!((uFlags & SND_MEMORY) || > - ((uFlags & SND_RESOURCE) && !((DWORD)pszSoundA >> 16)) || > - !pszSoundA)) { > - pszSoundW = HEAP_strdupAtoW(GetProcessHeap(), 0, pszSoundA); > - bSound = sndPlaySoundW(pszSoundW, uFlags); > + pszSoundW = (MULTIMEDIA_IsString(uFlags, pszSoundA)) ? > + HEAP_strdupAtoW(GetProcessHeap(), 0, pszSoundA) : (LPWSTR)pszSoundA; > + > + bSound = sndPlaySoundW(pszSoundW, uFlags); > + if ((void*)pszSoundW != (void*)pszSoundA) > HeapFree(GetProcessHeap(), 0, pszSoundW); > - } else > - bSound = sndPlaySoundW((LPWSTR)pszSoundA, uFlags); > > return bSound; > } -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

winedefault.reg and .Default user entries
by Sylvain Petreolle 16 May '02

16 May '02

Hi, Looking at recent patches, I saw entries for the user .Default in winedefault.reg. Are these entries useful ? I think not because wine uses the real username to load registry entries from the $HOME/.wine/user.reg. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: wine-20020509/dlls/winsock/socket.c
by Francois Gouget 16 May '02

16 May '02

Please, see Warren Baird's (Warren_Baird(a)cimmetry.com) patch on this and my reply to wine-devel. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: Patch - check for msghdr.msg_control on Sparc-Solaris
by Francois Gouget 16 May '02

16 May '02

On Thu, 16 May 2002 Warren_Baird(a)cimmetry.com wrote: > > > > ChangeLog: > > - added a test for the msg_control field in struct msghdr > (does't appear in sparc-solaris) I think it would be better to do it using a technique similar to how it is done in scheduler/client.c on line 255: #ifdef HAVE_MSGHDR_ACCRIGHTS msghdr.msg_accrights = (void *)&fd; msghdr.msg_accrightslen = sizeof(fd); #else /* HAVE_MSGHDR_ACCRIGHTS */ cmsg.len = sizeof(cmsg); cmsg.level = SOL_SOCKET; cmsg.type = SCM_RIGHTS; cmsg.fd = fd; msghdr.msg_control = &cmsg; msghdr.msg_controllen = sizeof(cmsg); msghdr.msg_flags = 0; #endif /* HAVE_MSGHDR_ACCRIGHTS */ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

1 0

Re: wine/programs/winetest wtmain.c
by Dimitrie O. Paun 16 May '02

16 May '02

On May 16, 2002 04:32 pm, Alexandre Julliard wrote: > Log message: > Better usage message. Flush stderr before exiting. And I thought stderr was unbuffered... -- Dimi.

2 1

Ignore my query
by Medland, Bill 16 May '02

16 May '02

Again, two minutes after posting the message it becomes clear. (bug in wineps; for some reason the name has a leading space on all after the first name extracted from printcap) Bill

1 0

Re: wine/dlls/winmm mmsystem.c winemm.h
by Michael Stefaniuc 16 May '02

16 May '02

Hello, this patch has introduced a regression, see http://bugs.winehq.com/show_bug.cgi?id=684 for details. bye michael On Sat, May 11, 2002 at 10:10:27PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1021173026714339351122366 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 02/05/11 22:10:27 > > Modified files: > dlls/winmm : mmsystem.c winemm.h > > Log message: > Eric Pouech <eric.pouech(a)wanadoo.fr> > Better behavior of PlaySound (error handling, synchronization). > Removed some unnecessary tests about windows handles. > > Patch: http://cvs.winehq.com/patch.py?id=1021173026714339351122366 > > Revision Changes Path > 1.52 +178 -204 wine/dlls/winmm/mmsystem.c > 1.11 +14 -0 wine/dlls/winmm/winemm.h -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Before I go mad, what am I doing wrong?
by Medland, Bill 16 May '02

16 May '02

I've been bashing my head against this all morning; can anyone tell me WHY I am an idiot. (Context - basically I have the task of putting together a Wine rpm tailored particularly to our application, for use by those who have been so spolied by M$ that they can't be bothered with the work involved in setting up wine from elsewhere. As part of that I am trying to figure out and improve the documentation on printing. As a result I am getting to understand that my copy is probably only working by chance). For as long as I can remember I have been using the "Wine Postscript Driver" solution on my machine, and also had "lp" configured as the same thing. I did not have a [ppd] section in my config. /etc/printcap mentions three JetDirect printers (well, four now; see below) I just added a [ppd] section into the config and added entries for each of the three (or 4) printers as follows: [ppd] "lp" = "/home/medbi01/bin/lopt612.ppd" "colour" = "/home/medbi01/bin/lopt612.ppd" "duplex" = "/home/medbi01/bin/lopt612.ppd" "mp" = "/home/medbi01/bin/lopt612.ppd" (the colour and duplex are lies but forget that for now) Now when I start notepad I get err:psdrv:PSDRV_FindPrinterInfo Error 2 getting PPD file name for printer 'colour' and similarly for duplex and mp, but not for lp. I (eventually) went into the code (dlls/psdrv/init.c) and modified the code to see the error code coming back from when it asked the registry for the lp, mp, colour, duplex. It returns 2 for mp, colour, duplex but SUCCESS for lp. OH!! I've just changed the default printer to "mp"and now it's the lp, colour and duplex it doesn't find. i.e. it finds the first one it asks about but not the next. So it sounds like something to do with the registry code. But now I've added the "generic" entry and removed my debug print code and it doesn't "complain". But without the "generic" it does. So maybe it's the fact that they all have the same value? No. Does this make any sense to anyone? Bill p.s. I'm going to see if it is "the first access to a registry key tends to fail".

1 0

Component owner for mouse input
by Andriy Palamarchuk 16 May '02

16 May '02

Are there volunteers to handle issues with mouse input? Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Re: [Bug 448] Changed - winsock 16 bit
by Uwe Bonnes 16 May '02

16 May '02

>>>>> "David" == David Barrena <david(a)molina.subs.map.es> writes: David> I can´t find socket.c in ...dlls/winsock/. Where is it?. Is a David> bynary Winsows app. Thanks. hertz:/spare/bon/wine> find -name \*sock\*.c ./dlls/wsock32/wsock32.spec.c ./dlls/wsock32/wsock32.dll.dbg.c ./dlls/wsock32/socket.c ./dlls/winsock/winsock.spec.c ./dlls/winsock/tests/sock.c ./dlls/winsock/socket.c ./server/sock.c -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: PATCH: error message if winedefault.reg is not loaded
by Andriy Palamarchuk 16 May '02

16 May '02

--- Marcus Meissner <marcus(a)jet.franken.de> wrote: [skipped] > + MESSAGE("\nERROR: You need to merge the > 'winedefault.reg' file into your\n"); > + MESSAGE(" WINE registry by running: `regapi > setValue < winedefault.reg'!\n\n"); > + } else { Marcus, we have already regedit (based on regapi), so the old regapi application is obsolete. Regedit call in this case will be as: regedit winedefault.reg Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Migrating from winehq.com to winehq.org in files
by Vincent Béron 16 May '02

16 May '02

This patch is to replace all the instances of winehq.com by winehq.org in the various files of the Wine distribution: documentation, comments, etc. There's also one pointer to appdb.codeweavers.com changed to appdb.winehq.org. I didn't touch at the ChangeLog and ChangeLog.Old files, and to an old email from Alexandre in documentation/HOWTO-Winelib, as I don't think it's a good idea to change such things. A similar patch has also been sent to web-admin(a)winehq.org, to change the files on the website. After the application of both, the only remaining thing would be the name of the CVS module (Winehq_com). Please comment. Vincent diff -urN wine-orig/ANNOUNCE wine/ANNOUNCE --- wine-orig/ANNOUNCE Fri May 10 08:40:00 2002 +++ wine/ANNOUNCE Wed May 15 22:44:46 2002 @@ -3,7 +3,7 @@ and unimplemented features. Most applications still do not work correctly. -Patches should be submitted to "wine-patches(a)winehq.com". Please don't +Patches should be submitted to "wine-patches(a)winehq.org". Please don't forget to include a ChangeLog entry. WHAT'S NEW with Wine-20020509: (see ChangeLog for details) @@ -32,7 +32,7 @@ and wine-doc.ps.gz. You can also get the current source directly from the CVS tree. Check -http://www.winehq.com/development/ for details. +http://www.winehq.org/development/ for details. If you submitted a patch, please check to make sure it has been included in the new release. @@ -46,4 +46,4 @@ -- Alexandre Julliard -julliard(a)winehq.com +julliard(a)winehq.org diff -urN wine-orig/BUGS wine/BUGS --- wine-orig/BUGS Sun May 5 22:41:48 2002 +++ wine/BUGS Wed May 15 22:47:42 2002 @@ -8,7 +8,7 @@ If you want to help Wine project you can: - * visit Bugzilla (http://bugs.winehq.com/) for + * visit Bugzilla (http://bugs.winehq.org/) for list of existing bugs. Metabug 406 lists bugs which are reasonably simple to fix even for someone new to Wine. Have a look at it and choose subject you are insterested in. @@ -26,7 +26,7 @@ * run Windows applications, port open-source Windows applications to Wine, fix bugs you found, enter bugs you can't fix to Bugzilla. Enter information you discovered to the - Wine Application Database (http://appdb.codeweavers.com/). + Wine Application Database (http://appdb.winehq.org/). * grep for FIXME in the source files diff -urN wine-orig/README wine/README --- wine-orig/README Fri May 10 08:40:00 2002 +++ wine/README Wed May 15 22:46:22 2002 @@ -22,7 +22,7 @@ problem resolution, read the rest of this file, the Wine man page, the files in the documentation directory of the Wine source (see "DOCUMENTATION"), and especially the wealth of information -found at http://www.winehq.com. +found at http://www.winehq.org. 3. REQUIREMENTS @@ -141,7 +141,7 @@ Don't forget to add vital registry entries by applying winedefault.reg with programs/regapi/. See documentation/ directory for details. -See http://www.winehq.com/support/ for further configuration hints. +See http://www.winehq.org/support/ for further configuration hints. In case of library loading errors (e.g. "Error while loading shared libraries: libntdll.so"), make sure @@ -202,15 +202,15 @@ 8. GETTING MORE INFORMATION WWW: A great deal of information about Wine is available from WineHQ at - http://www.winehq.com/ : various Wine Guides, application database, + http://www.winehq.org/ : various Wine Guides, application database, bug tracking. This is probably the best starting point. -FAQ: The Wine FAQ is located at http://www.winehq.com/FAQ +FAQ: The Wine FAQ is located at http://www.winehq.org/FAQ Usenet: You can discuss Wine-related issues and get help on comp.emulators.ms-windows.wine. -Bugs: Report bugs to Wine Bugzilla at http://bugs.winehq.com/. +Bugs: Report bugs to Wine Bugzilla at http://bugs.winehq.org/. Please search the bugzilla database to check whether your problem is already found before posting a bug report. You can also post bug reports to comp.emulators.ms-windows.wine. @@ -223,16 +223,16 @@ IRC: Online help is available at channel #WineHQ on irc.openprojects.net. CVS: The current Wine development tree is available through CVS. - Go to http://www.winehq.com/development/ for more information. + Go to http://www.winehq.org/development/ for more information. Mailing lists: There are several mailing lists for Wine developers; see - http://www.winehq.com/development/#ml for more information. + http://www.winehq.org/development/#ml for more information. If you add something, or fix a bug, please send a patch (in 'diff -u' -format) to wine-patches(a)winehq.com list for inclusion in the next +format) to wine-patches(a)winehq.org list for inclusion in the next release. -- Alexandre Julliard -julliard(a)winehq.com +julliard(a)winehq.org diff -urN wine-orig/documentation/HOWTO-winelib wine/documentation/HOWTO-winelib --- wine-orig/documentation/HOWTO-winelib Sat Feb 2 13:03:55 2002 +++ wine/documentation/HOWTO-winelib Wed May 15 22:35:49 2002 @@ -774,7 +774,7 @@ THANKS Most of the information in this file came from postings on -<Wine-devel(a)Winehq.com> and from private e-mails. The following people +<Wine-devel(a)winehq.org> and from private e-mails. The following people contributed information for this document and I thank them for their time and effort in answering my questions. I also want to thank them for encouraging me to attack the MFC problem. diff -urN wine-orig/documentation/authors.ent wine/documentation/authors.ent --- wine-orig/documentation/authors.ent Wed Dec 13 16:52:37 2000 +++ wine/documentation/authors.ent Wed May 15 22:32:15 2002 @@ -32,7 +32,7 @@ <!entity email-james-juran "juran(a)cse.psu.edu"> <!entity name-ove-kaaven "Ove Kåven"> -<!entity email-ove-kaaven "ovek(a)winehq.com"> +<!entity email-ove-kaaven "ovek(a)winehq.org"> <!entity name-eric-kohl "Eric Kohl"> <!entity email-eric-kohl "ekohl(a)abo.rhein-zeitung.de"> @@ -73,7 +73,7 @@ <!entity email-john-richardson "jrichard(a)zko.dec.com"> <!entity name-douglas-ridgway "Douglas Ridgway"> -<!entity email-douglas-ridgway "ridgway(a)winehq.com"> +<!entity email-douglas-ridgway "ridgway(a)winehq.org"> <!entity name-adam-sacarny "Adam Sacarny"> <!entity email-adam-sacarny "magicbox(a)bestweb.net"> diff -urN wine-orig/documentation/bugs.sgml wine/documentation/bugs.sgml --- wine-orig/documentation/bugs.sgml Sun May 5 22:41:49 2002 +++ wine/documentation/bugs.sgml Wed May 15 22:32:36 2002 @@ -21,7 +21,7 @@ </para> <para> With using either approach report the found issues with relevant - <ulink url="http://bugs.winehq.com/">Wine Bugzilla</ulink>. + <ulink url="http://bugs.winehq.org/">Wine Bugzilla</ulink>. </para> <sect2> @@ -54,7 +54,7 @@ <listitem> <para> Post the bug to - <ulink url="http://bugs.winehq.com/">Wine Bugzilla</ulink>. + <ulink url="http://bugs.winehq.org/">Wine Bugzilla</ulink>. Please, search Bugzilla database to check whether your problem is already found before posting a bug report. Include your own detailed description of the problem with @@ -196,7 +196,7 @@ <listitem> <para> Post the bug to - <ulink url="http://bugs.winehq.com/">Wine Bugzilla</ulink>. + <ulink url="http://bugs.winehq.org/">Wine Bugzilla</ulink>. Please, search Bugzilla database to check whether your problem is </para> <para> @@ -215,7 +215,7 @@ If after reading this document there is something you couldn't figure out, or think could be explained better, or that should have been included, please post to - <ulink url="http://bugs.winehq.com/">Wine Bugzilla</ulink> to + <ulink url="http://bugs.winehq.org/">Wine Bugzilla</ulink> to let us know how this document can be improved. </para> </sect2> diff -urN wine-orig/documentation/configuring.sgml wine/documentation/configuring.sgml --- wine-orig/documentation/configuring.sgml Wed May 8 21:04:46 2002 +++ wine/documentation/configuring.sgml Wed May 15 22:32:57 2002 @@ -930,7 +930,7 @@ <para> There is always a chance that things will go wrong. If the unthinkable happens report the problem to - <ulink url="http://bugs.winehq.com/">Wine Bugzilla</ulink>, + <ulink url="http://bugs.winehq.org/">Wine Bugzilla</ulink>, try the newsgroup <systemitem>comp.emulators.ms-windows.wine</systemitem>, or the IRCnet channel <systemitem>#WineHQ</systemitem> found on @@ -2012,7 +2012,7 @@ <para> from your main Wine directory, then submit <filename>layout.diff</filename> to - <email>wine-patches(a)winehq.com</email> along with a brief note + <email>wine-patches(a)winehq.org</email> along with a brief note of what it is. </para> <para> diff -urN wine-orig/documentation/cvs-regression.sgml wine/documentation/cvs-regression.sgml --- wine-orig/documentation/cvs-regression.sgml Tue Oct 16 17:47:51 2001 +++ wine/documentation/cvs-regression.sgml Wed May 15 22:33:23 2002 @@ -63,7 +63,7 @@ </para> <note> <para> - If you use Cvs directly from the winehq.com server, do not + If you use Cvs directly from the winehq.org server, do not forget to add to your <filename>.cvsrc</filename> file: </para> <screen> @@ -87,7 +87,7 @@ The date format is <literal>YYYY-MM-DD HH:MM:SS</literal>. Using the EDT date format ensure that you will be able to extract patches in a way that will be compatible with the - wine-cvs archive : http://www.winehq.com/hypermail/wine-cvs + wine-cvs archive : http://www.winehq.org/hypermail/wine-cvs </para> <para> Many messages will inform you that more recent files have diff -urN wine-orig/documentation/documentation.sgml wine/documentation/documentation.sgml --- wine-orig/documentation/documentation.sgml Tue Oct 2 13:48:16 2001 +++ wine/documentation/documentation.sgml Wed May 15 22:33:41 2002 @@ -953,7 +953,7 @@ <listitem> <para> Hyperlink in URL form, e.g., <ulink - url="http://www.winehq.com">http://www.winehq.com</ulink>. + url="http://www.winehq.org">http://www.winehq.org</ulink>. </para> </listitem> </varlistentry> diff -urN wine-orig/documentation/fonts.sgml wine/documentation/fonts.sgml --- wine-orig/documentation/fonts.sgml Fri May 10 08:40:00 2002 +++ wine/documentation/fonts.sgml Wed May 15 22:33:53 2002 @@ -18,7 +18,7 @@ Wine. It can be found in the <filename>tools</filename> directory. Links to the other tools mentioned in this document can be found on wine headquarters: - <ulink url="http://www.winehq.com/development/">http://www.winehq.com/development/</ulink> + <ulink url="http://www.winehq.org/development/">http://www.winehq.org/development/</ulink> </para> </note> </para> diff -urN wine-orig/documentation/getting.sgml wine/documentation/getting.sgml --- wine-orig/documentation/getting.sgml Fri May 10 08:40:00 2002 +++ wine/documentation/getting.sgml Wed May 15 22:35:02 2002 @@ -46,7 +46,7 @@ Finally, you may someday need to know how to apply a source code patch to your version of Wine. Perhaps you've uncovered a bug in Wine, reported it to the <ulink - url="mailto:wine-devel@winehq.com">Wine mailing list</ulink>, + url="mailto:wine-devel@winehq.org">Wine mailing list</ulink>, and received a patch from a developer to hopefully fix the bug. The last section in this chapter will show you how to <link linkend="getting-upgrading">safely apply the @@ -131,7 +131,7 @@ <para> The first place you should look if your system isn't Debian or Redhat is the <ulink - url="http://www.winehq.com/download/">WineHQ Download + url="http://www.winehq.org/download/">WineHQ Download Page</ulink>. This page lists many assorted archives of binary (precompiled) Wine files. </para> @@ -160,7 +160,7 @@ <para> The safest way to grab the source is from one of the official FTP archives. An up to date listing is in the <ulink - url="http://www.winehq.com/source/ANNOUNCE">ANNOUNCE </ulink> + url="http://www.winehq.org/source/ANNOUNCE">ANNOUNCE </ulink> file in the Wine distribution (which you would have if you already downloaded it). Here is a (possibly out of date) list of FTP servers carrying Wine: @@ -212,8 +212,8 @@ <para> The official web page for Wine CVS is - <ulink url="http://www.winehq.com/development/"> - http://www.winehq.com/development/</ulink>. + <ulink url="http://www.winehq.org/development/"> + http://www.winehq.org/development/</ulink>. </para> <para> First, you need to get a copy of the latest Wine sources @@ -223,14 +223,14 @@ <command>bash</command>, it might look something like this: </para> <screen> -$ export CVSROOT=:pserver:cvs@cvs.winehq.com:/home/wine +$ export CVSROOT=:pserver:cvs@cvs.winehq.org:/home/wine $ cvs login Password: cvs $ cvs checkout wine </screen> <para> That'll pull down the entire Wine source tree from - winehq.com and place it in the current directory (actually + winehq.org and place it in the current directory (actually in the 'wine' subdirectory). CVS has a million command line parameters, so there are many ways to pull down files, from anywhere in the revision history. Later, you can grab just @@ -278,7 +278,7 @@ distribution, you have the option of applying patches to the source tree to fix bugs and add experimental features. Perhaps you've found a bug, reported it to the <ulink - url="mailto:wine-devel@winehq.com">Wine mailing list</ulink>, + url="mailto:wine-devel@winehq.org">Wine mailing list</ulink>, and received a patch file to fix the bug. You can apply the patch with the <command>patch</command> command, which takes a streamed patch from <filename>stdin</filename>: diff -urN wine-orig/documentation/installation-und-konfiguration.german wine/documentation/installation-und-konfiguration.german --- wine-orig/documentation/installation-und-konfiguration.german Fri May 10 08:40:00 2002 +++ wine/documentation/installation-und-konfiguration.german Wed May 15 22:36:14 2002 @@ -254,7 +254,7 @@ Verwendung der Bash kann dazu der folgende Befehl eingegeben werden: - export CVSROOT=:pserver:cvs@cvs.winehq.com:/home/wine + export CVSROOT=:pserver:cvs@cvs.winehq.org:/home/wine Danach kann man sich bei dem CVS-Server anmelden. Hierzu dient dieser Befehl: @@ -284,7 +284,7 @@ u.a. in der Manualseite zu cvs(1) sowie auf der CVS-Homepage, die unter http://www.sourcegear.com/CVS zu erreichen ist. Weitere wichtige Hinweise im Hinblick auf CVS und WINE sind unter der Adresse - http://www.winehq.com/development/ verfügbar. + http://www.winehq.org/development/ verfügbar. 6.0 Konfiguration und Übersetzung des Quellcodes @@ -2088,6 +2088,6 @@ Weiterführende Informationen Die zentrale Web-Adresse für Informationen zu WINE ist - http://www.winehq.com. Dort befinden sich Links zu vielen weiteren + http://www.winehq.org. Dort befinden sich Links zu vielen weiteren Dokumenten, wie einem WINE-FAQ, einem WINE-HOWTO, einer Anleitung zum Erstellen von Fehlerberichten und vieles mehr. diff -urN wine-orig/documentation/make_winehq wine/documentation/make_winehq --- wine-orig/documentation/make_winehq Tue Jan 29 12:52:29 2002 +++ wine/documentation/make_winehq Wed May 15 22:36:42 2002 @@ -3,7 +3,7 @@ ## John R. Sheets <jsheets(a)codeweavers.com> ## This is a convenience script for building the website docs for -## www.winehq.com. It creates tarballs of the HTML with special +## www.winehq.org. It creates tarballs of the HTML with special ## server-side includes and CSS settings that aren't appropriate for ## the mainline Wine tree. For this reason, and to make it easier to ## set up an automated website update system, I'm putting this in @@ -18,7 +18,7 @@ ## $ ./make_winehq ## $ rsync ... -WWWDIR=www.winehq.com +WWWDIR=www.winehq.org ## Want to put this into a sub-directory for easier maintenance if [ -d "$WWWDIR" -o -f "$WWWDIR" ]; then rm -rf "$WWWDIR.old" @@ -76,7 +76,7 @@ ## Done creating downloadable tarballs for users. Now we want to ## create a tarball of SHTML in a slightly different form, for the ## website. These versions use special server-side includes which -## aren't appropriate outside of winehq.com. +## aren't appropriate outside of winehq.org. ## ## Use the special website stylesheet export WINEDOC_STYLESHEET=../winehq.dsl diff -urN wine-orig/documentation/packaging.sgml wine/documentation/packaging.sgml --- wine-orig/documentation/packaging.sgml Tue Apr 30 20:46:05 2002 +++ wine/documentation/packaging.sgml Wed May 15 22:37:00 2002 @@ -850,7 +850,7 @@ For an excellent overview of this issue, read this - <ulink url="http://www.winehq.com/News/2000-25.html#FTR"> + <ulink url="http://www.winehq.org/News/2000-25.html#FTR"> Wine Weekly News feature.</ulink> </para> diff -urN wine-orig/documentation/wine.man.in wine/documentation/wine.man.in --- wine-orig/documentation/wine.man.in Fri May 10 08:40:00 2002 +++ wine/documentation/wine.man.in Wed May 15 22:38:32 2002 @@ -307,11 +307,11 @@ .SH BUGS .PP A status report on many applications is available from -.I http://www.winehq.com/Apps. +.I http://appdb.winehq.org/. Please add entries to this list for applications you currently run. .PP Bug reports may be posted to Wine Bugzilla -.I http://bugs.winehq.com +.I http://bugs.winehq.org If you want to post a bug report, please read the file .I documentation/bugs.sgml in the @@ -319,7 +319,7 @@ source to see what information is necessary .PP Problems and suggestions with this manpage please also report to -.I http://bugs.winehq.com +.I http://bugs.winehq.org .SH AVAILABILITY The most recent public version of .B wine @@ -333,12 +333,12 @@ The latest snapshot of the code may be obtained via CVS. For information on how to do this, please see .I -http://www.winehq.com/development/ +http://www.winehq.org/development/ .PP WineHQ, the .B wine development headquarters, is at -.I http://www.winehq.com/. +.I http://www.winehq.org/. This website contains a great deal of information about .B wine. .PP @@ -354,7 +354,7 @@ development, you might want to subscribe to the .B wine mailing lists at -.I http://www.winehq.com/development/#ml +.I http://www.winehq.org/development/#ml .SH FILES .PD 0 .TP diff -urN wine-orig/documentation/wine.texinfo wine/documentation/wine.texinfo --- wine-orig/documentation/wine.texinfo Mon Mar 18 21:10:35 2002 +++ wine/documentation/wine.texinfo Wed May 15 22:40:35 2002 @@ -340,7 +340,7 @@ The overall coordination is done by @* Alexandre Julliard @* -@email{julliard@@winehq.com} +@email{julliard@@winehq.org} @@ -405,7 +405,7 @@ The Wine USENET newsgroup @url{news:comp.emulators.ms-windows.wine} is useful for both Wine developers and Wine users. The Wine home page -is @url{http://www.winehq.com/}. +is @url{http://www.winehq.org/}. @node Wine Design, Reference Manual, Introduction, Top @chapter Wine Design @@ -1658,7 +1658,7 @@ patches}, for details. @item -Mail the patch to Alexandre Julliard, @email{julliard@@winehq.com}. +Mail the patch to the wine-devel mailing list, @email{wine-devel@@winehq.org}. @item Wait for the patch to appear in the official distribution. @@ -1731,7 +1731,7 @@ patches}, for details. @item -Mail the patch to Alexandre Julliard, @email{julliard@@winehq.com}. +Mail the patch to the wine-devel mailing list, @email{wine-devel@@winehq.org}. @item Wait for the patch to appear in the official distribution. diff -urN wine-orig/documentation/winelib-bindlls.sgml wine/documentation/winelib-bindlls.sgml --- wine-orig/documentation/winelib-bindlls.sgml Tue Oct 2 13:48:16 2001 +++ wine/documentation/winelib-bindlls.sgml Wed May 15 22:37:17 2002 @@ -85,7 +85,7 @@ # linux library libMyLinux) # # For further details of wine spec files see the Winelib documentation at -# www.winehq.com +# www.winehq.org name MyWin type win32 diff -urN wine-orig/documentation/winelib-porting.sgml wine/documentation/winelib-porting.sgml --- wine-orig/documentation/winelib-porting.sgml Fri May 18 17:01:44 2001 +++ wine/documentation/winelib-porting.sgml Wed May 15 22:37:26 2002 @@ -279,7 +279,7 @@ <para> If you come across a difference between the Windows headers and Wine's that breaks compilation, try asking for help on - <email>wine-devel(a)winehq.com</email>. + <email>wine-devel(a)winehq.org</email>. </para> </sect1> diff -urN wine-orig/programs/notepad/README wine/programs/notepad/README --- wine-orig/programs/notepad/README Wed Mar 20 17:55:46 2002 +++ wine/programs/notepad/README Wed May 15 22:51:10 2002 @@ -13,4 +13,4 @@ Please see file TODO for things to do and keep the file ChangeLog up to date. -I also try to read wine-devel(a)winehq.com frequently. +I also try to read wine-devel(a)winehq.org frequently. diff -urN wine-orig/programs/notepad/main.h wine/programs/notepad/main.h --- wine-orig/programs/notepad/main.h Wed Mar 20 17:55:46 2002 +++ wine/programs/notepad/main.h Wed May 15 22:51:22 2002 @@ -31,7 +31,7 @@ /* hide the following from winerc */ #ifndef RC_INVOKED -#define WINE_RELEASE_INFO "Wine (www.winehq.com)" +#define WINE_RELEASE_INFO "Wine (www.winehq.org)" #include "commdlg.h" diff -urN wine-orig/tools/bug_report.pl wine/tools/bug_report.pl --- wine-orig/tools/bug_report.pl Wed May 8 21:04:47 2002 +++ wine/tools/bug_report.pl Wed May 15 22:52:13 2002 @@ -75,7 +75,7 @@ the second has *all* of the debug output, which can go to thousands of lines. To (hopefully) get the bug fixed, report it to the project - bug tracking system at http://bugs.winehq.com. + bug tracking system at http://bugs.winehq.org. Attach the first file to the bug description. Also include detailed description of the problem. The developers might ask you for "the last X lines from the report". If so, just @@ -567,7 +567,7 @@ }; $var30 = qq{ Having problems with the script? -Submit a bug report to Wine bugtracking system at http://bugs.winehq.com or +Submit a bug report to Wine bugtracking system at http://bugs.winehq.org or tell the wine newsgroup (comp.emulators.ms-windows.wine). }; print do_var($var22); diff -urN wine-orig/tools/genpatch wine/tools/genpatch --- wine-orig/tools/genpatch Sat Mar 9 19:24:22 2002 +++ wine/tools/genpatch Wed May 15 22:52:33 2002 @@ -1,7 +1,7 @@ #!/usr/bin/perl # # genpatch - A utility that generates patches for submission to -# wine-patches(a)winehq.com +# wine-patches(a)winehq.org # # Copyright Steven Elliott <elliotsl(a)mindspring.com> # @@ -23,7 +23,7 @@ =head1 NAME genpatch - A utility that generates patches for submission to -wine-patches(a)winehq.com +wine-patches(a)winehq.org =head1 SYNOPSIS diff -urN wine-orig/tools/winedump/winedump.h wine/tools/winedump/winedump.h --- wine-orig/tools/winedump/winedump.h Sat Mar 9 19:24:24 2002 +++ wine/tools/winedump/winedump.h Wed May 15 22:53:10 2002 @@ -20,7 +20,7 @@ * References: * DLL symbol extraction based on file format from alib (anthonyw.cjb.net). * - * Option processing shamelessly cadged from winebuild (www.winehq.com). + * Option processing shamelessly cadged from winebuild (www.winehq.org). * * All the cool functionality (prototyping, call tracing, forwarding) * relies on Patrik Stridvall's 'function_grep.pl' script to work. diff -urN wine-orig/tools/wineinstall wine/tools/wineinstall --- wine-orig/tools/wineinstall Wed May 15 22:28:46 2002 +++ wine/tools/wineinstall Wed May 15 22:52:55 2002 @@ -363,7 +363,7 @@ echo "'$sucommand' correctly." echo "If you didn't enter an incorrect password then please report this" echo "error and any steps to possibly reproduce it to" - echo "http://bugs.winehq.com/" + echo "http://bugs.winehq.org/" echo echo "Installation failed, aborting." exit 1 diff -urN wine-orig/tools/wmc/wmc.man wine/tools/wmc/wmc.man --- wine-orig/tools/wmc/wmc.man Tue Jun 13 00:34:42 2000 +++ wine/tools/wmc/wmc.man Wed May 15 22:53:20 2002 @@ -97,7 +97,7 @@ WineHQ, the .B wine development headquarters, at -.I http://www.winehq.com/. +.I http://www.winehq.org/. .SH "SEE ALSO" .BR wine (1), .BR wrc (1) diff -urN wine-orig/tools/wrc/wrc.man wine/tools/wrc/wrc.man --- wine-orig/tools/wrc/wrc.man Fri Aug 25 17:32:18 2000 +++ wine/tools/wrc/wrc.man Wed May 15 22:53:29 2002 @@ -226,6 +226,6 @@ WineHQ, the .B wine development headquarters, at -.I http://www.winehq.com/. +.I http://www.winehq.org/. .SH "SEE ALSO" .BR wine (1),

1 0

talk-through dll
by Lonnie Cumberland 16 May '02

16 May '02

Hello All, I have been reading over the Wine documentation but have not come across this yet. I am interested in having a windows DLL that can access some functions native to Linux. For instance, possibly an application under wine that allows me to add a new user to my Linux box. My guess is that I should be able to write up a windows dll that will talk to Linux. Is this correct? If so then where in the Wine docs can I read more about the specifics of how this can be done? Thanks in advance, Lonnie

3 5

Re: wine/ ./Make.rules.in debugger/.cvsignore dlls ...
by Eric Pouech 15 May '02

15 May '02

> Added winebuild support for generating a .dbg.c file containing the > debug channels definitions. > Made win32 the default type for spec files. > Ignore C compiler in winebuild so we can simply pass it $(DEFS). > Removed type win32 and debug_channels from spec files. > Fixed winebuild to always generate correct C identifiers (reported by > Vincent Béron). > one comment about this patch: the c correct identifier isn't perfect (program name can start with a digit, whereas C ident can't) A+

2 1

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