wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

command line options and registry questions
by Christian Costa 09 Jun '02

09 Jun '02

Hi winers! The command line -winver option has been removed. I found that this option was quite convenient because : 1) it can be used easily in shortcut (in KDE for example) 2) when you don't know the windows version an app runs on, it is easier to test until you match the right one. Is there a reason for this removal ? Moreover it seems that some wine configuration are stored in the registry (the windows version for each apps for example). Is it wise to use the registry for wine specific configuration ? Personaly, I think a very cool feature could be to specify a registry file when invoking wine. So, you don't have to worried about breaking an app while installing another. A+ Christian

1 0

Locale support
by P. Christeas 09 Jun '02

09 Jun '02

I haven't looked at wine code yet. However, I think I have an idea about locale use both in KDE and glibc-based programs. Those two use a totally different subsystem: KDE uses Qt unicode support from QString class. glibc has locale functions and supports both wide (16-bit) and byte (8-bit) strings. Here, nothing is expected to work until you call the set_locale fn. In both cases, applications (including wine) have to be locale-aware in order for things to work. Most of the apps currently have lots of bugs related to locales in strings. You can ask for my help in such cases, as I am strongly for internatinalized programms.

1 0

[Fwd: [BUGZILLA] Security Advisory For Versions of Bugzilla 2.14 Prior To 2.14.2, 2.16 Prior To 2.16rc2]
by Shachar Shemesh 09 Jun '02

09 Jun '02

FYI.

1 0

Word2K crash (window management, remote)
by Andreas Mohr 09 Jun '02

09 Jun '02

Hi all, crash for Word2K, current CVS, Insert->Object...->Microsoft WordArt 2.0: 153 if (!(parentWnd->dwStyle & WS_CLIPCHILDREN) && parentWnd->hrgnUpdate) Wine-dbg>bt Backtrace: =>0 0x405ebaae (WIN_HaveToDelayNCPAINT+0x3e(hwnd=0x1004b, uncFlags=0x0) [painting.c:153] in user32.dll.so) (ebp=40566cb4) 1 0x405ec571 (RDW_Paint+0x81(wndPtr=0x403980a0, hrgn=0x0, flags=0x50, ex=0x0) [painting.c:606] in user32.dll.so) (ebp=40566ce0 2 0x405ecae5 (RedrawWindow+0x3b1(hwnd=0x1004b, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x50) [painting.c:801] in user32.dll.so) (ebp=40566d4c) 3 0x40614ba9 (PeekMessageW+0xfd(msg_out=0x447030, hwnd=0x0, first=0x0, last=0x0, flags=0x0) [message.c:2103] in user32.dll.so) 4 0x40614c1b (PeekMessageA+0x27(msg=0x447030, hwnd=0x0, first=0x0, last=0x0, flags=0x0) [message.c:2126] in user32.dll.so) (ebp=40566dbc) 5 0x0040ce4f (Wrdart32.exe..text+0xbe4f in C:\Program Files\Common Files\Microsoft Shared\WordArt\Wrdart32.exe) (ebp=00447030) 6 0x00000532 (ebp=00020040) inf loc: hwnd == 0x1004b uncFlags == 0 parentWnd == 0 The parent window seems to be a valid window handle, but the parent wnd *ptr* becomes NULL -> crash. Sounds like some code nullifies the valid parent window handle in between. Of course I suppose that window locking was supposed to take care of this. Seems like this isn't exactly the case here ;-) Any ideas ? Hmm, wait, in a trace I just found: trace:win:RedrawWindow 10048 (16a6) NULL 0,0-0,0 0000 flags=0050 trace:win:OffsetRect <- 0,0-78,13 trace:win:RDW_UpdateRgns hwnd 10048 [16a6] -> hrgn [0000], flags [0050] trace:win:RDW_Paint hwnd 10048 [16a6] -> hrgn [0000], flags [0050] err:win:WIN_FindWndPtr window 10022 belongs to other process 093bda98:Call kernel32.UnhandledExceptionFilter(40454900) ret=0043854a wine: Unhandled exception, starting debugger... So it seems like the parent window is in another process and thus WIN_FindWndPtr fails to return the handle and returns NULL. Should we handle the possibility of a foreign parent window handle by not doing anything in case of a NULL parent wndPtr in WIN_HaveToDelayNCPaint() ? Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

Games, Stuff and Whatnot
by Phil Bordelon 08 Jun '02

08 Jun '02

Hello there. I've been following the wine-devel--and, more recently, the wine-license--mailing lists for some time now. While I am a competent C and C++ programmer, I haven't had the time to really come up-to-speed with the Windows API enough to help in re-implementing it. [Part of that comes from an aversion to even learning enough about the Windows API to re-implement it.] Nevertheless, for a considerable period of time before I switched entirely to Linux, I happened to be a professional video-game reviewer. I was the primary PC game reviewer for the site, and because of that I happen to have legitimate copies of just about every major PC release for the past two years, not counting stuff in the last handful of months. [I have Max Payne, but not Morrowind, and so on.] I also happen to be a game collector, and over the years I've picked up a number of games even older than those, including a game (Surface Tension) that uses what I believe to be pre-3.0 DirectX. Meep! Anyway, the point of this letter is this--if people are planning on starting on an implementation of the whole Direct3D/DirectX thing for the WineHQ wine, I'm willing to be an official 'guinea pig.' I can provide any developer working on this with a list of games I own, and we can start banging away on getting them to work. There is one caveat: I don't reboot into Windows, so it'll have to be installable under Linux. While some older games work already, the InstallShield work from Transgaming that they're putting into the ReWind tree is probably necessary before the recent stuff will work. Eventually, I'd like to help with the code as well, but I'd like to proffer what services I can right now. Phil -- "'Original .signatures are for wimps!' .signatures are for wimps!" .signatures are for wimps!

1 0

Problems converting DLL to unix SO with winelib
by list＠vmn.com.br 07 Jun '02

07 Jun '02

Hello All At Wine-Devel! I am trying to convert a win32 DLL to a unix SO. The dll named if32dt is basically a wrapper over the serial port, interfacing some custom hardware. It is therefore a driver to the custom hw. This is part of a project to port a windows sales app to linux. There are about 6 DLLs with similar structure and my aim is to show my superiors that using winelib is much better than simply rewriting the DLL to use unix system calls. 1) I have sucessfully copied my project over to unix and built the so file The project is basicaly a couple of headers and the c file ifdt32.cpp bash# cd ifdt32/ bash# mv ifdt32.cpp ifdt32.c #the file is plain C , cpp was confusing gcc bash# winemaker --nomfc -imsvcrt.dll -I/usr/local/include/wine/msvcrt --dll . bash# ./configure bash# make bash# make install The DLL uses msvcrt so I added it. => I read some issues between msvcrt and crt in winehq.com After changing a couple lines of ifdt.c I was able to build libifdt.so . I had a lot of warnings like ifdt32.c:176: warning: comparison between pointer and integer My ifdt32.spec file is unchanged from what winemaker created name ifdt32 type win32 mode dll init DllMain import msvcrt.dll import advapi32.dll import comdlg32.dll import gdi32.dll import kernel32.dll import ntdll.dll import odbc32.dll import ole32.dll import oleaut32.dll import shell32.dll import user32.dll import winspool.drv ifdt32.c only uses msvcrt.dll, ntdll.dll , kernel32.dll, user32.dll I added simple printf calls to DllMain to see if it was being called when the SO is loaded make install correctly put libifdt.so in /usr/local/lib I ran ldconfig in /usr/local/lib with bash# ldconfig -v -n . libifdt32.so -> libifdt32.so libwine_unicode.so -> libwine_unicode.so.1.0 libwine_tsx11.so -> libwine_tsx11.so.1.0 libwine.so -> libwine.so.1.0 2) I created a trivial program to test libifdt.so bash# cat test.c #include "windows.h" #include "stdio.h" #include "stdlib.h" #include "string.h" #include "io.h" #include "conio.h" #include "fcntl.h" #include "direct.h" #include "time.h" #include "IFfunc32.h" printf("before start"); int main(void) { printf("before start"); if( IF_IFDT32_OPEN("COM2") == 0 ) { printf("We are working") ; } else { printf("Oh no!"); } } bash# make gcc -g -c test.c -I/usr/local/include/wine -I/usr/local/include/wine/msvcrt -I/home/nwine/ifdt32/ifdt32 gcc -o test test.o -lifdt32 -L/usr/local/lib This program seg faults. I have not been able to debug it with winedbg, it simply hangs with message "Starting with pid 0" bash# gdb test (gdb) b 1 Breakpoint 1 at 0x8048556: file test.c, line 1. (gdb) r Starting program: /home/nwine/ifdt32/test/test Breakpoint 1, main () at test.c:15 15 printf("before start"); (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x400387cb in dllname () from /usr/local/lib/libifdt32.so (gdb) bt #0 0x400387cb in dllname () from /usr/local/lib/libifdt32.so #1 0x8048563 in main () at test.c:15 #2 0x40057f9b in __libc_start_main () from /lib/libc.so.6 (gdb) p dllname $1 = "ifdt32" In this trace, it seems that a function named dllname is causing a segfault There is a string named dllname and it's contents are correct I think the winelib initialisation code has not been correctly called For example: the Dllmain function to start the DLL has not been called I have tried a great many things to work around this problem with no success. It is hard to debug because the seg fault happens very early and I havent been able to get winedbg to work. I have tried this on wine-20020509 and wine-20020122 with exactly the same problem. Thanks a lot for any help or pointers. Miguel Feitosa Sao Paulo - Brasil P.S> output of bash# ldd ifdt.dll libwine.so => /usr/local/lib/libwine.so (0x40010000) libwine_unicode.so => /usr/local/lib/libwine_unicode.so (0x40026000) libm.so.6 => /lib/libm.so.6 (0x40103000) libc.so.6 => /lib/libc.so.6 (0x40125000) libdl.so.2 => /lib/libdl.so.2 (0x40245000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000) ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

2 1

How to compile to include debug info
by Medland, Bill 07 Jun '02

07 Jun '02

I am trying to track down a problem that is resulting in an attempt to dereference the null pointer. Very conveniently this happens in some code for which I have the source. However winedbg reckons there is no debug information in the DLL. This is not true; there is an enormous amount in there so I guess its in the wrong format. Can anyone tell me which settings I need when compiling the DLL under VC6++ in order to allow winedbg to understand the information and give me a usable stack trace? Bill

1 0

Call for testers
by Johan Gill 07 Jun '02

07 Jun '02

Quoting a comment I made for bug# 722: This is troublesome. I can fix this problem by reenabling these things in dlls/version/info.c: /* Temporary workaround a broken behaviour of the 16-bit loader */ len = 0; /* VERSION_GetFileVersionInfo_16(filename, handle, 0, NULL); */ /* Temporary workaround a broken behaviour of the 16-bit loader */ len = 0; /* VERSION_GetFileVersionInfo_16(filename, &handle, datasize, data); */ Doing so, however, is said to break installation of Office 2000. I don't have Office 2000, so it's quite impossible for me to know what's wrong. I would like to hear from anyone having it, and who is willing to try installation of it with those calls reenabled.

1 0

Re: Problems converting DLL to unix SO with winelib
by list＠vmn.com.br 07 Jun '02

07 Jun '02

Martin, Thanks for your help. I see from your output that the diff file is correct. I think my email program is messing with the contents of the email. I had diferent errors from your email than I had from the web page. I tried editing some of the diff file but it was hopeless.... I didnt get a nice patch like your output suggests. I dont know what to put into the spec file. I read everything but winebuild source. I am not familiar enough with ELF, linking etc to understand what is going on in the source. I havent been able to get a simple example to compile and work either. This simple example doesnt need to import any Dlls. It seems that I am not writing the spec file correctly. Therefore, winelib is not init ing correctly and my DllMain function is not being called when the Shared Object inits. Any pointers? Can you send me the diff file gzipped or whatever so I can finaly make the patch work? Thanks, Miguel Quoting Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com>: > Am Fre, 2002-06-07 um 16.59 schrieb mfeitosa(a)vmn.com.br: > > > Here is the output... > > And here is mine: > > [martin@biker tools]$ cvs diff -u -r 1.39 winemaker > [martin@biker tools]$ cd .. > [martin@biker wine]$ patch -p0 --dry-run </tmp/winemaker.diff > patching file tools/winemaker > patching file documentation/winemaker.man > [martin@biker wine]$ > > Perhaps you have the wrong patch. I attach it. > Martin > > -- > Martin Wilck Phone: +49 5251 8 15113 > Fujitsu Siemens Computers Fax: +49 5251 8 20409 > Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com > D-33106 Paderborn http://www.fujitsu-siemens.com/primergy > > > > > ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

1 0

Simple Windows DLL does not work correctly with winelib - HELP
by list＠vmn.com.br 07 Jun '02

07 Jun '02

Hello All, I am trying to create a shared object from a DLL with winelib. I have been unable to make things work. Therefore I made a small example that points out the issues I am facing. I certainly appreciate your help. This has been tested on the last two versions of wine. wine-20020509 and 20020605 Say I had a windows DLL defined in mytest.c as #include <windows.h> #include <stdio.h> BOOL APIENTRY DllMain(HINSTANCE hinstDLL , DWORD fdwReason, LPVOID lpvReserved ) { printf("DllMain called"); return TRUE; } void usefullFunction() { printf("Usefull function got called"); } I put mytest.c inside a directory called mytest I then call winemaker as winemaker --dll --nomfc . I edit libmytest.spec so it looks like name meuteste type win32 mode dll init DllMain I then call configure make and make install I edit a file called callmytest.c #include "mytest.h" int main(void) { usefullFunction(); } After compiling, when calling ./callmytest I get output: Usefull function got called =>Supposed to get "DllMain got called" too It seems winelib is not initializing correctly and calling DllMain... It seems that the spec file format changed and so my spec file is incorrect. [Thanks Martin Wilck for your help) I read the libwine manual in winehq.com , wine/tools/winebuild/README , wine-devel list etc and still cant see what else I should do. Can someone help me get this simple example to work? Thanks, Miguel Feitosa This is output from make clean all rm -f *.spec.c y.tab.c y.tab.h lex.yy.c core *.orig *.rej \#*\# *~ *% .\#* meuteste.o libmeuteste.spec.o libmeuteste.tmp.o libmeuteste.so gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o meuteste.o meuteste.c ld -r meuteste.o -o libmeuteste.tmp.o strip --strip-unneeded libmeuteste.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym libmeuteste.tmp.o -o libmeuteste.spec.c -spec ./libmeuteste.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o libmeuteste.spec.o libmeuteste.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o libmeuteste.so meuteste.o libmeuteste.spec.o -lwine -lwine_unicode -lwine_uuid -lm ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

1 0

Need help debugging problem w/Quicken
by Carl Sopchak 07 Jun '02

07 Jun '02

I'm trying to get Quicken 2000 Deluxe running under Wine (on a Red Het 7.3 box). In order to use Quicken the way I want to, I need to have the internet connection going (for stock price updates). However, when I try to configure it, I can't get anywhere. When I press Edit -> Internet Connection Setup, the cursoe goes to an hourglass and hangs. If I move the cursor after that, it goes back to a normal arrow pointer. The setup dialog never pops up. I'm using the current CVS version of Wine (as of this morning, June 7). Now, I'm VERY new to Wine, and know less about Windows internals, but I've been in similar postitions and successfully resolved similar problems - with a little help... I guess I'm looking for some tips on how to debug this. I currently have these specific questions: 1) Is networking support implemented in wine yet (even partially)? If not, I guess I'll have to wait a while, as I'm not in a position (knowledge or time wise) to write something like that from scratch :-(. If it is implemented,... 2) I know about --debugmsg, and the four classes of debug messages, but I haven't come across many debug channel names, besides all, relay, and snoop. But the amount of messages that these generate lend them to be pretty unusable. Can someone point me to a list of names, tell me how to find the names in the source, or at least give me a few names that might be helpful in debuggin my problem? 3) I'm guessing that I'll probably need some documentation on the WinAPI. Does Microsoft have that on their web site? (If not, where might I find it?) 4) Does anyone know of a version of Quicken (>= Q2000) that already runs on wine? I'd be willing to upgrade if it would solve my problem... Thanks for any help you can give! Hopefully my work on this will improve wine in some small way... Carl

2 1

Deffered Debugmessages patch side effect
by Uwe Bonnes 07 Jun '02

07 Jun '02

Hallo, recent changes in debugmsg messages affected the --debugmsg -XXX behaviour. Now this command lines is a NOP. Bye -- 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: Problems converting DLL to unix SO with winelib
by list＠vmn.com.br 07 Jun '02

07 Jun '02

Wow, now I really lost it... I have tried to remove the imports from the spec file but then I get unresolved symbols when linking the so.. So what should it contain? Where is [if at all] the documentation for the spec file... Thanks, Miguel Quoting Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com>: > Hi, > > winemaker in CVS is broken. Your "spec" file should not contain any > "imports" anymore, for example. > > I have submitted a patch for this a while ago to this list ("winemaker > fixes", 2002/05/22), which doesn't seem to have made it into CVS. > > Martin > > -- > Martin Wilck Phone: +49 5251 8 15113 > Fujitsu Siemens Computers Fax: +49 5251 8 20409 > Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com > D-33106 Paderborn http://www.fujitsu-siemens.com/primergy > > > > > ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

2 2

ttc & sbit patch
by Won Kyu Park 07 Jun '02

07 Jun '02

Hello, This is a quick hack for ttc fonts and it enables embeded sbits in ttc/ttf with a recent freetype library. It is based on a Korean patch but I don't know who make it :-) Regards, Won kyu Park

1 0

WinExec16 in shlexec.c
by Steven Edwards 07 Jun '02

07 Jun '02

Can we use CreateProcess here instead if WinExec? I only have this and about 6 other things stopping the mingw build Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

Minor build system change for the Windows ports
by Steven Edwards 07 Jun '02

07 Jun '02

Anyone got any input on this? We need to be able to link to imports for kernel32 other then the standard libkernel32.a. Mingw doesn't keep all of the kernel32 import information in libkernel32.a instead it is like MSVC where it has a libth32.a and libthunk32.a. What is needed here is a change to the build system that allows for importing of these libs at link time when building a dll that needs those exports. Psapi.dll needs the toolhelp lib and one of the directx dlls needs the libthunk. I submitted a dirty patch for this a week or two ago but it wasn't accepted. The other option is to make the "make implib" rule and change the search path for the import libs. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

Re: dlls/shell32/dialogs.c:RunFileDlg - implemented
by Nix N. Nix 06 Jun '02

06 Jun '02

On Thu, 2002-06-06 at 11:20, Nix N. Nix wrote: > On Thu, 2002-06-06 at 09:14, Mike McCormack wrote: > > > > You'd better use cvs diff -u (you can add diff -u to your ~/.cvsrc so as > > not to forget). > > > > You should just submit the changelog entries like this: > > > > Well, here it is with these mods then. I removed the stuff from the > ChangeLog file. Everything quoted below still holds. > > > ChangeLog: > > Added RunFileDlg with MRU list (based on the template found in > > Win98 shell32.dll) Added template to all .rc files Translated the hungarian copy of "Wine was brought to you by" > > > > Looks like good work though! I have updated the patch such that it modifies shell32_*.rc (except shell32_xx.rc, of course) to include the dialog box template. I have translated where I could. I also translated the "Wine was brought to you by:" string in shell32_Hu.rc . If you want me to put that in a separate patch, please let me know. > > > > Mike > > > > Nix N. Nix wrote: > > > I implemented RunFileDlg from dlls/shell32/dialogs.c, together with the > > > MRU list that Windoze has. I placed the MRU list stuff in the same > > > registry key as in Windoze. I had to add a dependency. The > > > "&Browse..." button requires commdlg. I didn't know how to do this in > > > the Makefile, so I used LoadLibraryEx. > > > > > > Well, here it is (diff is against CVS from around Wed Jun 5 16:00:00 > > > EDT 2002) > > Thanks for the help.

1 0

RE: Where is ELF stab documented?
by Medland, Bill 06 Jun '02

06 Jun '02

> -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland@accpac.com] > Sent: Thursday, June 06, 2002 3:57 PM > To: Wine devel (E-mail) > Subject: RE: Where is ELF stab documented? > SNIP > > There is a GNU stabs documentation but I think it is not > complete. The > > only complete one might be the one in the gcc source :/ > > That's what I thought. Thanks anyway. > > Bill > or maybe http://sources.redhat.com/gdb/onlinedocs/stabs_toc.html Bill

1 0

Re: Winehq: Bugzilla responsibilities page
by Andreas Mohr 06 Jun '02

06 Jun '02

On Wed, May 29, 2002 at 12:06:22PM -0700, Andriy Palamarchuk wrote: > Changelog: > Added bugzilla responsibilities page. Hi, hmm, I'm not 100% sure about this. - why did you remove bug tracking link ? - "Talking Back" probably isn't very descriptive. I'd add something like "... (bugs etc.)" - that's Albe*r*telli - Application owners play *an* important role in the bugs handling process. - why add a whole new talkback.inc ? isn't that a bit overkill ? - why is <li>Bugs Hunting Guide</li> non-functional text ? Wow, questions over questions :-) Good job with bugz_resp.inc, BTW !! Needless to say I'll add this immediately as soon as these questions are covered :) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

3 4

RE: Where is ELF stab documented?
by Medland, Bill 06 Jun '02

06 Jun '02

> -----Original Message----- > From: Marcus Meissner [mailto:marcus@jet.franken.de] > Sent: Thursday, June 06, 2002 3:26 PM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Where is ELF stab documented? > > > On Thu, Jun 06, 2002 at 03:14:45PM -0700, Medland, Bill wrote: > > For the sheer heck of it I was going to have a look at bug > 650. I know its > > not a high priority or anything but it intrigued me. > Anyway, to look into > > it I would want decent documentation on the format of the > stab/stabstr > > sections of the ELF files to understand what the parser > should be doing. > > Does anyone know where I can find that information? I > didn't see anything > > immediately in the Intel v1.1 specification. > > It appears not harmful (libstdc++ is pulled by libXrender.so here). > > Oh and the new debugging format of gcc 3.1 is DWARF-2, not stabs > anymore. > > There is a GNU stabs documentation but I think it is not complete. The > only complete one might be the one in the gcc source :/ That's what I thought. Thanks anyway. Bill

1 0

Do we need Direct3D? How about OpenGL?
by Roland 06 Jun '02

06 Jun '02

Hello, I just thought about this. AFAIK most good 3D games support OpenGL anyway. That means, they can run without D3D, right? If this is true maybe it would be more of an advantage to concentrate on other parts of DirectX first. Postpone D3D to a later moment...in a few years or so :)) Roland

3 2

How big is the Direct3D stuff?
by Roland 06 Jun '02

06 Jun '02

Hello, since it seems that TG is not going to release their D3D stuff, my question is: why is it so difficult to reimplement this? How big is the amount of code? Roland

6 9

Where is ELF stab documented?
by Medland, Bill 06 Jun '02

06 Jun '02

For the sheer heck of it I was going to have a look at bug 650. I know its not a high priority or anything but it intrigued me. Anyway, to look into it I would want decent documentation on the format of the stab/stabstr sections of the ELF files to understand what the parser should be doing. Does anyone know where I can find that information? I didn't see anything immediately in the Intel v1.1 specification. Bill

2 1

Re: opengl32 wglSwapLayerBuffers
by Lionel Ulmer 06 Jun '02

06 Jun '02

> I do think it's odd as well since a more basic function can handle it. > fixme:opengl:wglSwapLayerBuffers (0000087c, 00000001) > ..repeated until exiting the game. > > So it's basically switching the main layer over and over again? Yes, so they are simply 'emulating' SwapBuffers with the 'wglSwapLayerBuffers' call (as they only request swapping of the main buffer as shown by the 0x00000001 parameter given to the fuPlane parameter). > I don't think it uses other layers. Because I think there would be a > graphics corruption if it did. None have been observed so far. Anyway, as seen in the trace you posted, they seem to not use it. > Heh, since I'm a beta tester, I can ask blizz why they even use this > function, and see if they respond. You could always try... > And it's the best running game I've seen running under wine. =) A pity I am not a fan of RTS games :-) Lionel (wondering if MacOS X is not to thank for all those OpenGL + D3D games coming out) -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: imports by ordinal
by juergen.schmied＠debitel.net 06 Jun '02

06 Jun '02

>> I'd like to use in a internal wine-dll(shell32) a function exported >> by an other dll(shlwapi) by ordinal. How can I do this in a clean >> way without use of GetProcAddress in a way it works with native >> dll's too? >You have to use GetProcAddress, there is no automatic import >mechanism. That's a feature to discourage you from calling ordinal >functions ;-) shlwapi.dll exports quite a lot of functions to shell32 what would mean a lot of duplicate code ;-(. juergen

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel