wine-devel

wine-devel@winehq.org

9 participants
84458 discussions

Re:Question about using DLL generated by winemaker
by dd jj 23 Jul '03

23 Jul '03

Sorry, I forgot to mention my formal command which generate ping.dll.so ... %winemaker --lower-uppercase . %./configure --with-wine-includes=/usr/local/include/wine/windows %make Thank you. -Lechun Hello Rodrick, Thanks a lot for your advices, now I am able to use winemaker to generate ping.dll.so (it take me a long time, lots of copiler errors there :) ). But somehow when I run my application under wine: %wine ./ping.exe It just terminate itself. (I suppose it should wait for user's input here) but it return back to prompt state: % Did you happen to know what's the problem, I checked it and found it seems the pin.dll.so works, but somehow terminate the whole program... really wield. All the best. -Lechun Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: The tool winedump is used if I'm right to create a "stub" (empty) dll from a M$ dll. In your case since you have the source code and all you should use winemaker. There are dozens of options to give it to create an exectuble, a library and so on. Just copy the full windows source over and winemaker should create makefiles. Good Luck, Roderick On Sunday 20 July 2003 23:29, dd jj wrote: > Hello, > > After reading winedump/README, I am still confused about how to generate a > wine dll since there's no example described. > > Originally I followed the example described by "spec mode: Generating stub > DLLs", later I found what I need is to "reimplement a Win32 DLL for Unix", > I am wondering whether anyone can give a detailed sample to show how to do > that... > > Now I have 'pingdll.dll'(generated by MS visual studio), and source code > 'pingdll.h','pingdll.c'... > > So my final goal is to generate a wine dll - pingdll.dll.so taking place of > native dll(ping.dll) completly which can be called when I run:( I also need > to change the wine's config to anounce 'Dlloveride: "pingdll" = > "builtin,native") > > % wine ./ping.exe > > In such a way, I can implement some functionality through linux shared > library without the restriction of WINE spave if using native dll under > WINE). > > Could you please help me out of this? > > Thanks a lot. > > -Lechun > > Steven Edwards wrote: > > Now I am trying to use winemaker to build a winelib dll from windows > > source code, Could anyone give some instructions about the implementation > > details? Or any useful info and samples there? > > It seems to me the easy way to build a WINElib dll ATM is not to use > Winemaker but to use winedump to create the spec and add the dll to > wine/dlls/newdllname. > > Thanks > Steven > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > --------------------------------- > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software

1 0

Question about using DLL generated by winemaker.
by dd jj 22 Jul '03

22 Jul '03

Hello Rodrick, Thanks a lot for your advices, now I am able to use winemaker to generate ping.dll.so (it take me a long time, lots of copiler errors there :) ). But somehow when I run my application under wine: %wine ./ping.exe It just terminate itself. (I suppose it should wait for user's input here) but it return back to prompt state: % Did you happen to know what's the problem, I checked it and found it seems the pin.dll.so works, but somehow terminate the whole program... really wield. All the best. -Lechun Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: The tool winedump is used if I'm right to create a "stub" (empty) dll from a M$ dll. In your case since you have the source code and all you should use winemaker. There are dozens of options to give it to create an exectuble, a library and so on. Just copy the full windows source over and winemaker should create makefiles. Good Luck, Roderick On Sunday 20 July 2003 23:29, dd jj wrote: > Hello, > > After reading winedump/README, I am still confused about how to generate a > wine dll since there's no example described. > > Originally I followed the example described by "spec mode: Generating stub > DLLs", later I found what I need is to "reimplement a Win32 DLL for Unix", > I am wondering whether anyone can give a detailed sample to show how to do > that... > > Now I have 'pingdll.dll'(generated by MS visual studio), and source code > 'pingdll.h','pingdll.c'... > > So my final goal is to generate a wine dll - pingdll.dll.so taking place of > native dll(ping.dll) completly which can be called when I run:( I also need > to change the wine's config to anounce 'Dlloveride: "pingdll" = > "builtin,native") > > % wine ./ping.exe > > In such a way, I can implement some functionality through linux shared > library without the restriction of WINE spave if using native dll under > WINE). > > Could you please help me out of this? > > Thanks a lot. > > -Lechun > > Steven Edwards wrote: > > Now I am trying to use winemaker to build a winelib dll from windows > > source code, Could anyone give some instructions about the implementation > > details? Or any useful info and samples there? > > It seems to me the easy way to build a WINElib dll ATM is not to use > Winemaker but to use winedump to create the spec and add the dll to > wine/dlls/newdllname. > > Thanks > Steven > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > > --------------------------------- > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software

1 0

which of these should I work on?
by Jonathan Wilson 22 Jul '03

22 Jul '03

After looking at all the things windows provides, I have identified the folowing possible programs that I could write for the wine project. Some of them are usefull for WINE itself and some of them might be usefull for (for example) ReactOS Things: 1.improve comdlg32.dll, implement stuff added in WINVER>=0x500 like PrintDlgEx and generally make comdlg32.dll behave more like the windows counterpart (implement a few other things as well, like some of the currently stubbed out items). 2.work on wine notepad. Wont do this until the changes refered to before are merged. 3.write a clone of fontview.exe (windows font sample viewer). This is probobly not usefull for WINE but might be usefull for ReactOS, plus it would be a good excercise in windows GDI programming. 4.write clones of guidgen.exe and/or uuidgen.exe, 2 different windows SDK tools for generating GUIDs/UUIDs. (if we are providing an IDL compiler and other such OLE-esque things, having a GUID/UUID generator is probobly a good thing to have, mainly it is just a stub around a call to CoCreateGUID 5.write a clone of rebase.exe, a win32 PE image rebasing tool. Probobly not usefull to WINE but might be helpfull for ReactOS development, dont know. 6.writing a clone of the cards.dll used by the windows card games. Only problem here is that I would need to find a sutably licenced set of card images since I dont have the skills to draw them myself :) 7.writing a clone of the card games (solitare,freecell etc) included with windows to use said cards.dll (hey, we have WineMine...) 8.writing a character map applet (basicly a clone of charmap.exe). Dont know if WINE needs this but ReactOS probobly does (how else are you going to insert all those fancy foreign language characters and dingbats? :) 9.writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might... and 10.writing a clone of the Win32 volume control applet. Dont think WINE needs this (since the linux sound API has one already) but ReactOS might... Which of these should I work on? Which of these are usefull to Wine/ReactOS? Are any of these considered "a big beast" (as richedit was refered to by Dimitrie O. Paun?)

8 8

Re: [RESENT] PATCH: dlls/comctl32/listview.c - ScrollColumns fails if no columns exist
by Dimitrie O. Paun 22 Jul '03

22 Jul '03

On Tue, 22 Jul 2003, Stefan Haller wrote: > Resolution: > Attached updated diff based on snapshot 20030709 fixes the problem. > > Changelog: > * dlls/comctl32/listview.c > Stefan Haller <sh_at_grep.ch> > - Ignoring LISTVIEW_ScrollColumns() request if no columns in list Looks good! -- Dimi.

1 0

Re: new utillity for wine, genguid
by Alexandre Julliard 22 Jul '03

22 Jul '03

Jonathan Wilson <jonwil(a)tpgi.com.au> writes: > ok, is this better? > Included as one big patch > Also, added blank line, changed coding to 4 spaces instead of tab > and, changed options to use what you suggested. It looks good, but I'm not convinced we really need that in Wine, there are Unix tools that can generate UUIDs. -- Alexandre Julliard julliard(a)winehq.com

2 1

visual age c++
by ahmed hafez 22 Jul '03

22 Jul '03

2 1

Re: Mach-O Support in WineLib Loader (2) dlopen
by Alexandre Julliard 22 Jul '03

22 Jul '03

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > This patch provides Mach-O support in WineLib. As Mach-O doesn't have > init and fini section, it adds support for it in dlopen. A new file > mach-o.c is created. It contains functions which add support for init, > and fini section. Isn't there any way to have an init function? How does Mach-O support C++ constructors? -- Alexandre Julliard julliard(a)winehq.com

3 4

I am going to implement cards.dll
by Jonathan Wilson 22 Jul '03

22 Jul '03

As I said in my other message "Its not only used by the MS card games but others as well. Its been reverse engineered by some people and also at some point MS released an "official" SDK for it (at http://www.microsoft.com/mind/0396/games.asp ) so if we dont clone it, people cant play non-ms games that use it" However, there is a problem. Microsoft released a 16 bit version of cards.dll. Later on, they relased a new 32 bit version, also called cards.dll. Some games support the 16 bit version via thunks, some support the 32 bit version and some games try and detect both. Firstly, is there some way I can implement cards.dll so that it presents the 16 bit interface to those apps that use the 16 bit thunks to talk to it and also so it presents the 32 bit interface to those apps that talk to it as a 32 bit dll? Also, I am trying to catalog all the different versions of cards.dll that are out there. (in an attempt to catalog all the differences) I personally have: 1.cards.dll from Windows XP, size 359,936 version 5.1.2600.0. This one is a 32 bit version. 2.cards.dll from Win2k, size 153,360 version 5.0.2134.1. This one is a 32 bit version. 3.cards32.dll from the microsoft article linked to above, size 152,064, no versioninfo resource. This one is a 32 bit version. 4.cards.dll from win98, size 148,528, no versioninfo. This one is a 16 bit version. Does anyone have any other versions, especially other 16 bit versions? BTW, I am going to use the cards from http://www.jfitz.com/cards/index.html. As for the backs, anyone want to draw some? :)

3 2

Re: Progress bar painting fix
by Dimitrie O. Paun 22 Jul '03

22 Jul '03

On Thu, 17 Jul 2003, Mike McCormack wrote: > > ChangeLog: > * invalidate the whole progress bar when painting (for Dreamweaver's > install) That's just Not Cool (TM). It introduces a lot of flicker, and there has been a non-trivial amount of effort put into the invalidate routine to eliminate the annoying flicker. Maybe it's not perfect, but removing it altogether can't be the answer. -- Dimi.

3 4

Re: new utillity for wine, genguid
by Dimitrie O. Paun 22 Jul '03

22 Jul '03

On July 22, 2003 08:27 am, Jonathan Wilson wrote: > Feedback is appreciated (i.e. did I submit the patches correctly, is the -- please add everything as one big patch. To include the new files to the patch, just 'diff -u /dev/null <mynewfile> >> mypatch.diff' -- leave a blank line after the copyright in the header -- we don't force a coding style, but most code is written with indentation of 4 spaces, so that'd be good to follow. Also, be consistent we the braces, the prefered style is: if (...) { .... } -- use a more standard option format for the program, instead of a number (unless this is the way MS utility does it). Something like -O, -D, -c, -r, -u. -- Dimi.

1 0

Re: I am going to implement cards.dll (idea for handling the thunks stuff)
by Jonathan Wilson 22 Jul '03

22 Jul '03

Well basicly, the function names are the same in both the 16 bit dll and the 32 bit dll but one is 16 bit code and one is 32 bit code. The 16 bit version is loaded by LoadLibrary16 Probobly the best way to implement this is to make a cards.dll so that if its loaded by a 16 bit app or loaded via LoadLibrary16, it loads 16 bit code and provides the 16 bit version. If its loaded by LoadLibrary (or via an imports table) from a 32 bit app, the 32 bit version will be loaded. This way, it will work properly with all apps that use cards.dll (regardless of if they use the 16 bit or 32 bit versions) Although, I dont know if that would be a proper way to do it. Anyhow, I need some advice from the gurus on how best to handle this... BTW, there is at least one library that works with both versions by doing LoadLibrary and if that fails LoadLibrary16.

2 1

Palettes again
by Johan Gill 22 Jul '03

22 Jul '03

I'll try again: Run on a true- or high colour display, create a display DC compatible with the display and select&realize a palette into it. A subsequent call to GetSystemPaletteEntries gives no palette at all. Is that what Windows 98/2000/XP does? /Johan Gill <johane(a)lysator.liu.se>

1 0

how do you do console apps?
by Jonathan Wilson 22 Jul '03

22 Jul '03

How would one do an app as a WineLib app (much like how notepad etc are) but that is a console app? Is there an example somewhere in the wine tree of how to do a console app (with main() instead of winmain() and that uses stdio.h to do output to stdout and etc?)

2 1

Re: System tray integration take 5
by Alexandre Julliard 22 Jul '03

22 Jul '03

Mike Hearn <mike(a)theoretic.com> writes: > +#define MAX_TRAY_ICONS 256 > +int undockedTrayIconsCount = 0; > +static HWND undockedTrayIcons[MAX_TRAY_ICONS]; /* stores HWNDs of undocked tray windows when a > + NETWM tray window appears, we can dock */ You shouldn't use a global array here. This is not thread safe, plus you'd need to keep track of window destruction to remove them from the array. The right way IMO would be to walk the window tree checking for WS_EX_TRAYWINDOW at the time a tray window appears. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/programs/notepad rsrc.rc main.h main.c di ...
by Shachar Shemesh 22 Jul '03

22 Jul '03

> > >--- wine/programs/notepad/rsrc.rc:1.8 Mon Jul 21 20:38:52 2003 >+++ wine/programs/notepad/rsrc.rc Mon Jul 21 20:38:52 2003 >@@ -24,6 +24,20 @@ > #include "commctrl.h" > #include "notepad_res.h" > >+ID_ACCEL ACCELERATORS >+{ >+ "^A", CMD_SELECT_ALL >+ "^C", CMD_COPY >+ "^F", CMD_SEARCH >+ "^O", CMD_OPEN >+ "^S", CMD_SAVE >+ "^V", CMD_PASTE >+ "^X", CMD_CUT >+ "^Z", CMD_UNDO >+ VK_F3, CMD_SEARCH_NEXT, VIRTKEY >+ VK_F5, CMD_TIME_DATE, VIRTKEY >+} >+ > #include "Da.rc" > #include "De.rc" > #include "En.rc" > > > What's the sense in making the accelerators global to all languages? Each language has it's own accelerator keys (just as it has it's own menus). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

2 1

I now know what I am going to work on
by Jonathan Wilson 22 Jul '03

22 Jul '03

After all the feedback, I have decided to work on 4 things: 1.a fontview.exe clone (should give me good experiance in working with the GDI font APIs and also should give the WINE implementations of those APIs a workout. In particular, the functionality used to display a font even though its not registered with the system font lists should be a nice thing to hack on and figure out how its done. Plus, ReactOS can use the results. 2.a guidgen.exe clone (the origonal uses MFC, mine wont obviously) 3.a uuidgen.exe clone (usefull as a way to generate GUIDs/UUIDs from a script or makefile) and 4.a cards.dll clone. Its not only used by the MS card games but others as well. Its been reverse engineered by some people and also at some point MS released an "official" SDK for it (at http://www.microsoft.com/mind/0396/games.asp ) so if we dont clone it, people cant play non-ms games that use it :)

1 0

Once again: Wine without X?
by Dan Kegel 22 Jul '03

22 Jul '03

OK folks, it's time for my semiannual "I need Wine to run a commandline program, but can't get it to work" rant. First try: just do a default installation of wine-20030709. Log: $ wine -- /dos/d/vss/win32/ss.exe Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: x11drv: Can't open display: $ echo $DISPLAY $ That should have worked, since ss.exe doesn't use any GDI functions. Moving right along, now let's try the tty driver. I added "GraphicsDriver" = "ttydrv" dank@dank:~$ wine /dos/d/vss/win32/ss.exe dank@dank:~$ It blipped the display to a second screen, then when the program exited, the screen blipped back so I couldn't read what it said. That's pretty useless. In fact, this is exactly the behavior complained about in bug 1358 ( http://bugs.winehq.com/show_bug.cgi?id=1358 ) subtitled "GraphicsDriver" = "none" wanted. On the off chance that a "none" driver had been implemented, I tried it. And suprisingly, something sensible happened: dank@dank:~$ wine /dos/d/vss/win32/ss.exe help Could not load graphics driver 'none' fixme:console:SetConsoleCtrlHandler (0x449460,1) - no error checking or testing yet Username: It actually seemed to work, once past the warning! I haven't tested it beyond the password prompt yet, but that was pretty convincing. Is this the recommended way to run console wine programs without any $&?@!\% curses stuff kicking in and without X? And is there a chance of setting this behavior on a program-by-program basis? AppDefaults appears to be keyed off the driver already, so is probably not able to say "these apps should not use x11drv or ttydrv". Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

7 9

Re: Sync (29): msvcrt cpp
by Alexandre Julliard 22 Jul '03

22 Jul '03

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > +dlls/msvcrt/cpp.c > Use exception as the base for all exception derived classes. > Implement type_info methods correctly. > Add static RTTI for exported objects. > Throw exceptions when run time casts fail. Why did you remove all the structure definitions for the derived classes? I think it's much clearer to have a separate C type for each class instead of having everything be an exception object. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: shlwapi
by Alexandre Julliard 21 Jul '03

21 Jul '03

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > Numbers without prefix are int (32bit signed). If you > want long long (64bit signed), append LL. LL is not portable, this needs to be done with casts. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Avoid problems with glibc's _res symbol
by Mike Hearn 21 Jul '03

21 Jul '03

Isn't _res an internal function? If so, why is Wine using it? On Mon, 2003-07-21 at 10:06, Mike McCormack wrote: > Newer versions of glibc don't exporting the _res symbol, but instead > replace it with a function call of a different name. This breaks binary > compatibility for code using _res compiled and linked with older > versions of glibc. (iphlpapi uses _res) > > Mike > > > ChangeLog: > * dlopen libc to avoid problems with glibc's _res symbol, which only > defined in older glibc versions > > > ______________________________________________________________________ > Index: configure.ac > =================================================================== > RCS file: /home/wine/wine/configure.ac,v > retrieving revision 1.166 > diff -u -r1.166 configure.ac > --- configure.ac 16 Jul 2003 23:37:22 -0000 1.166 > +++ configure.ac 21 Jul 2003 02:45:13 -0000 > @@ -911,8 +911,8 @@ > WINE_GET_SONAME(jack,jack_client_new) > WINE_GET_SONAME(ssl,SSL_library_init) > WINE_GET_SONAME(crypto,BIO_new_socket) > + WINE_GET_SONAME(c, vsprintf) > fi > - > > dnl **** Check for functions **** > > Index: configure > =================================================================== > RCS file: /home/wine/wine/configure,v > retrieving revision 1.441 > diff -u -r1.441 configure > --- configure 16 Jul 2003 23:37:22 -0000 1.441 > +++ configure 21 Jul 2003 02:45:21 -0000 > @@ -2246,7 +2246,8 @@ > echo "$as_me:$LINENO: \$? = $ac_status" >&5 > (exit $ac_status); }; }; then > for ac_declaration in \ > - '' \ > + ''\ > + '#include <stdlib.h>' \ > 'extern "C" void std::exit (int) throw (); using std::exit;' \ > 'extern "C" void std::exit (int); using std::exit;' \ > 'extern "C" void exit (int) throw ();' \ > @@ -2260,8 +2261,8 @@ > cat confdefs.h >>conftest.$ac_ext > cat >>conftest.$ac_ext <<_ACEOF > /* end confdefs.h. */ > -$ac_declaration > #include <stdlib.h> > +$ac_declaration > int > main () > { > @@ -12977,8 +12978,72 @@ > #define SONAME_LIBCRYPTO "$ac_cv_lib_soname_crypto" > _ACEOF > fi > -fi > > +echo "$as_me:$LINENO: checking for -lc soname" >&5 > +echo $ECHO_N "checking for -lc soname... $ECHO_C" >&6 > +if test "${ac_cv_lib_soname_c+set}" = set; then > + echo $ECHO_N "(cached) $ECHO_C" >&6 > +else > + ac_get_soname_save_LIBS=$LIBS > +LIBS="-lc $LIBS" > + cat >conftest.$ac_ext <<_ACEOF > +#line $LINENO "configure" > +/* confdefs.h. */ > +_ACEOF > +cat confdefs.h >>conftest.$ac_ext > +cat >>conftest.$ac_ext <<_ACEOF > +/* end confdefs.h. */ > + > +/* Override any gcc2 internal prototype to avoid an error. */ > +#ifdef __cplusplus > +extern "C" > +#endif > +/* We use char because int might match the return type of a gcc2 > + builtin and then its argument prototype would still apply. */ > +char vsprintf (); > +int > +main () > +{ > +vsprintf (); > + ; > + return 0; > +} > +_ACEOF > +rm -f conftest.$ac_objext conftest$ac_exeext > +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 > + (eval $ac_link) 2>&5 > + ac_status=$? > + echo "$as_me:$LINENO: \$? = $ac_status" >&5 > + (exit $ac_status); } && > + { ac_try='test -s conftest$ac_exeext' > + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 > + (eval $ac_try) 2>&5 > + ac_status=$? > + echo "$as_me:$LINENO: \$? = $ac_status" >&5 > + (exit $ac_status); }; }; then > + ac_cv_lib_soname_c=`$ac_cv_path_LDD conftest$ac_exeext | grep libc\\.so | sed 's/^[ ]*$[^ ]*$[ ]*=>.*$/\1/'` > + if test "x$ac_cv_lib_soname_c" = "x" > + then > + ac_cv_lib_soname_c="libc.so" > + fi > +else > + echo "$as_me: failed program was:" >&5 > +sed 's/^/| /' conftest.$ac_ext >&5 > + > +ac_cv_lib_soname_c="libc.so" > +fi > +rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext > + LIBS=$ac_get_soname_save_LIBS > +fi > +echo "$as_me:$LINENO: result: $ac_cv_lib_soname_c" >&5 > +echo "${ECHO_T}$ac_cv_lib_soname_c" >&6 > +if test "x$ac_cv_lib_soname_c" != xNONE > +then > +cat >>confdefs.h <<_ACEOF > +#define SONAME_LIBC "$ac_cv_lib_soname_c" > +_ACEOF > +fi > +fi > > > # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works > Index: include/config.h.in > =================================================================== > RCS file: /home/wine/wine/include/config.h.in,v > retrieving revision 1.157 > diff -u -r1.157 config.h.in > --- include/config.h.in 20 Jun 2003 23:26:56 -0000 1.157 > +++ include/config.h.in 21 Jul 2003 02:45:22 -0000 > @@ -53,6 +53,9 @@ > /* Define to 1 if you have the <cups/cups.h> header file. */ > #undef HAVE_CUPS_CUPS_H > > +/* Define to the soname of the C library. */ > +#undef SONAME_LIBC > + > /* Define to 1 if you have the <curses.h> header file. */ > #undef HAVE_CURSES_H > > Index: dlls/iphlpapi/Makefile.in > =================================================================== > RCS file: /home/wine/wine/dlls/iphlpapi/Makefile.in,v > retrieving revision 1.1 > diff -u -r1.1 Makefile.in > --- dlls/iphlpapi/Makefile.in 13 May 2003 03:32:20 -0000 1.1 > +++ dlls/iphlpapi/Makefile.in 21 Jul 2003 02:45:22 -0000 > @@ -7,6 +7,7 @@ > > LDDLLFLAGS = @LDDLLFLAGS@ > SYMBOLFILE = $(MODULE).tmp.o > +EXTRALIBS = @DLLIBS@ > > C_SRCS = \ > ifenum.c \ > Index: dlls/iphlpapi/iphlpapi_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/iphlpapi/iphlpapi_main.c,v > retrieving revision 1.4 > diff -u -r1.4 iphlpapi_main.c > --- dlls/iphlpapi/iphlpapi_main.c 23 Jun 2003 03:32:28 -0000 1.4 > +++ dlls/iphlpapi/iphlpapi_main.c 21 Jul 2003 02:45:22 -0000 > @@ -29,6 +29,8 @@ > #include <arpa/nameser.h> > #endif > #include <resolv.h> > +#include <wine/library.h> > +#include <wine/port.h> > #include "winbase.h" > #include "iphlpapi.h" > #include "ifenum.h" > @@ -847,6 +849,35 @@ > return getIPStats(pStats); > } > > +/****************************************************************** > + * IPHLPAPI_GetResolver > + * > + * Finds the location of the DNS server list for GetNetworkParams > + */ > +#ifdef __GLIBC__ > +struct __res_state *IPHLPAPI_GetResolverState() > +{ > + static struct __res_state *p_res; > + static struct __res_state *(*p__res_state)(); > + static void *plibc; > + > + if( !plibc ) > + { > + plibc = wine_dlopen(SONAME_LIBC, RTLD_GLOBAL, NULL, 0 ); > + p__res_state = wine_dlsym(plibc, "__res_state", NULL, 0 ); > + p_res = wine_dlsym(plibc, "_res", NULL, 0 ); > + } > + > + if( p__res_state ) > + return p__res_state(); > + > + if( p_res ) > + return p_res; > + > + return NULL; > +} > +#endif /* __GLIBC */ > + > > /****************************************************************** > * GetNetworkParams (IPHLPAPI.@) > @@ -865,11 +896,22 @@ > DWORD WINAPI GetNetworkParams(PFIXED_INFO pFixedInfo, PULONG pOutBufLen) > { > DWORD size; > +#ifdef __GLIBC__ > + struct __res_state *p_res = IPHLPAPI_GetResolverState(); > +#endif > + int res_nscount = 0; > > if (!pOutBufLen) > return ERROR_INVALID_PARAMETER; > > - size = sizeof(FIXED_INFO) + min(1, (_res.nscount - 1) * > +#ifdef __GLIBC__ > + if( p_res ) > + res_nscount = p_res->nscount; > +#else > + res_nscount = _res.nscount; > +#endif > + > + size = sizeof(FIXED_INFO) + min(1, (res_nscount - 1) * > sizeof(IP_ADDR_STRING)); > if (!pFixedInfo || *pOutBufLen < size) { > *pOutBufLen = size; > @@ -881,14 +923,19 @@ > GetComputerNameExA(ComputerNameDnsHostname, pFixedInfo->HostName, &size); > size = sizeof(pFixedInfo->DomainName); > GetComputerNameExA(ComputerNameDnsDomain, pFixedInfo->DomainName, &size); > - if (_res.nscount > 0) { > + if ( res_nscount > 0) { > PIP_ADDR_STRING ptr; > int i; > > - for (i = 0, ptr = &pFixedInfo->DnsServerList; i < _res.nscount; > + for (i = 0, ptr = &pFixedInfo->DnsServerList; i < res_nscount; > i++, ptr = ptr->Next) { > +#ifdef __GLIBC__ > + toIPAddressString(p_res->nsaddr_list[i].sin_addr.s_addr, > + ptr->IpAddress.String); > +#else > toIPAddressString(_res.nsaddr_list[i].sin_addr.s_addr, > ptr->IpAddress.String); > +#endif > ptr->Next = (PIP_ADDR_STRING)((PBYTE)ptr + sizeof(IP_ADDRESS_STRING)); > } > }

3 3

Re: [MSDMO] Some methods implement and stubs added
by Dmitry Timoshkov 21 Jul '03

21 Jul '03

"Michael "GЭnnewig"" <MichaelGuennewig(a)gmx.de> wrote: > Changelog: > - Implemented Mo* methods in msdmo.dll > - Added stubs for DMORegister, DMOUnregister, DMOEnum, DMOGetTypes, > DMOGetName. > - Added version resources. Please use a usual Wine scheme for defining version resources, see existing resources for details. -- Dmitry.

2 3

More Red Hat b0rkage?
by Mike Hearn 21 Jul '03

21 Jul '03

I know Wine has some issues with some kernel security patches and memory regions. Can anybody confirm that this won't cause issues: The Red Hat Linux 9.0.93 kernel includes new Exec-shield functionality Exec-shield is a security-enhancing modification to the Linux kernel that makes large parts of programs — including their stack — not executable. This can reduce the potential damage of some security holes. Exec-shield is related to the older "non-exec stack patch" but has the potential to provide much greater protection. Exec-shield's behavior can be controlled via the proc file system. The command used is: echo <value> > /proc/sys/kernel/exec-shield thanks -mike

2 1

Question about WINE and adding the "low-level" CD access APIs...
by Jonathan Wilson 21 Jul '03

21 Jul '03

Many copy protections use special tricks on the CDs (I dont know the details). Presumably these protections use some kind of lower-level API to access the data on the CD directly (instead of going through the file I/O calls). Currently TransGaming does something specific for each kind of copy protection to make it work. Would it be possible to implement these APIs in WINE and have them redirect to whatever low level APIs are provided by linux/x/whatever? That way (assuming the implementation was complete), any copy protection would work (i.e. when the protection says "give me this bit of data from the CD in this form", WINE hooks that, gets the relavent data and returns it to the application. Same could be said for protections that use the "boot blocks" to store licence data (such as CDilla Licence Manager), for those you could hook the "read from boot block" and "write to boot block" calls and store the data somewhere (preferably not the real boot block :) If someone can tell me what the low-level access that these protections use is actually called (i.e. what search term to use in MSDN to look for documentation etc) as well as info on whatever the relavent linux low-level access stuff would be, I can look at drawing up some kind of "here is how this could be done" document. Similar low-level hooks could be used to allow things like AudioCatalyst (program that converts audio-cd tracks to MP3 files) and anything else that does lower level access to CDs/DVDs than the high-level file I/O APIs and etc. (the day its possible to run Nero Burning Rom in WINE with no problems will be a great day indeed for the project :) If this isnt fesable for copy protection and so on, please explain why (I know nothing about copy protection or how to program the CD-ROM in win32) Basicly, I dont understand why there is a need for "protection-specific" code in WineX when you could emulate whatever the protection uses and appear just like real windows to the game...

4 6

My wine turned to vinegar... vanilla wine isn't broken, is it?
by Gregory M. Turner 21 Jul '03

21 Jul '03

OK, this is a new problem to me... I'm not too familiar with the loader so I thought I'd see if anybody knew what was going on before I spent time trying to debug this myself. I recently decided that my wine installation had become too crufty, so I wiped out ~/c, and ~/.wine, and ran tools/wineinstall. This is with CVS wine... IOW, a 100% standard config. Everything seemed to go fine with wineinstall, but now, no matter what I try, I seem to be unable to run wine at all -- it more-or-less immediately segfautlts. I didn't change anything; aside from some truly trivial font path fixups, I have a completely vanilla ~/.wine/config and ~/c tree. Under gdb, I see the following if I try to run notepad (or any other thing): (gdb) up #1 0x4011ba3c in wine_dll_set_callback (load=0x400a7aa0 <load_library>) at loader.c:353 (gdb) print builtin_dlls[i].filename $6 = 0x400dcb95 "ntdll.dll" (gdb) down #0 map_dll (nt_descr=0x400f7b20) at loader.c:166 (gdb) bt #0 map_dll (nt_descr=0x400f7b20) at loader.c:166 #1 0x4011ba3c in wine_dll_set_callback (load=0x400a7aa0 <load_library>) at loader.c:353 #2 0x400a80c3 in BUILTIN32_LoadExeModule (main=0x0) at ../../relay32/builtin32.c:181 #3 0x403f5715 in __wine_process_init (argc=2, argv=0xbffff5f4) at ../../../wine/scheduler/process.c:578 #4 0x4011bc6a in wine_init (argc=2, argv=0xbffff5f4, error=0xbffff1a4 "", error_size=1024) at loader.c:427 #5 0x3c000540 in main (argc=2, argv=0xbffff5f4) at ../../wine/miscemu/main.c:33 #6 0x40237747 in __libc_start_main () from /lib/libc.so.6 (gdb) print ptr $7 = (void *) 0x41b (gdb) print base $8 = (void *) 0x0 It's deferencing the 0x41b pointer which is causing the segfault... Any ideas? If not, how should I try and debug this?... what is fixup_rva_ptr's (libs/wine/loader.c) all about? And, if this is what happens with a completely vanilla wine install, why doesn't "everybody" have this problem? Surely, I am missing something totally obvious? Thanks, -- "We must stop thinking of the individual and start thinking about what is best for society." -Hillary Clinton, 1993 gmt

4 5

Re: Mach-O Support in WineLib Loader
by Mike Hearn 21 Jul '03

21 Jul '03

Out of curiousity, how do you get around the linkage requirements of Mach-O, ie the fact that you can't both dlopen and runtime link to the same module? On Mon, 2003-07-21 at 13:08, Pierre d'Herbemont wrote: > Hi! > > This patch enables Mach-O (Darwin linker file format) support in > WineLib. > > Thanks, > > Pierre > > ModifiedFiles: > - loader/module.c > > ChangeLog: > - Add Mach-O (Darwin file format) support. >

2 1

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