December 2005 - Wine-devel - list.winehq.org

binary only dll , resolving links through winebuild
by Ananth M 19 Dec '05

19 Dec '05

Binary Only Dll (test.dll) with the header file (test.h) ------------------------------------------------------------------------- - I have a binary only dll (test.dll) that was created in windows which exports to functions - int Add (int, int) - int Subtract (int, int) - I want to use this dll in Linux from an application mydlltest.cpp. - In that process, I have tried the following: - Generated the .spec file using winedump - winedump spec test - This created the .spec file with stub functions 1 stub add 2 stub Subtract - Installed this dll as builtin dll in my wine directory (This is my testing purpose) - chmod a+x testdll_install - ./testdll_install <wine_path> - cd <wine_path> - autoconf - ./configure - make depend && make - Now I am able to see this dll in dlls directory of winepath I am not finding any README on Winebuild and I am getting problem from this step onwards, - NOW do I need to generate the .def for the spec file of the dll?? - NOW do I need to change any settings like DllOverrides to access this dll from my test application?? - Now I have a win32 application (mydlltest.cpp) that was using this dll in windows. - How can I link the (test.dll) from the application (mydlltest.cpp) ? - I use the LoadLibrary("test") in the test application ( mydlltest.cpp), the dll was loaded - I got the GetProcAddress() for the function "Add", the function pointer is obtained - *But when I call the function "add" from the application, I was getting exception*. - Then I define the stub function in the test_dll_main.c, to print a trace message. - Compiled the dll again to create the test.dll.so - Now, when I call the function "add" from the application, the trace message is printed, BUT THE ACTUAL FUNCTION IN THE TEST.DLL is not called. * (I Created the .def file from the .spec file of the dll and tried the same. Still I am getting the same problem)* ** * How I can use winebuild after creating the .spec file using winedump, so that I can link that dll using the Application.??* * Any detailed steps that can help in using a third party binary dll in Linux using the Test Applciation ??* Thank you AJ <wine-devel-bounces(a)winehq.org>

1 0

vbrun60sp6.exe doesn't work in Wine
by Dan Kegel 19 Dec '05

19 Dec '05

Wine-0.9.3 can install vbrun60sp5.exe and earlier just fine, but for some reason vbrun6sp6.exe silently exits without installing anything. Anyone know why? You can download it from http://support.microsoft.com/default.aspx?scid=kb;en-us;290887 -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 1

ReactOS has game I see......
by Tom Wickline 19 Dec '05

19 Dec '05

Hello, http://vogons.zetafleet.com/viewtopic.php?t=10750 :D Cheers, Tom

1 0

Switching from INI-Files (win9x) to Registry (NT)?
by Detlef Riekenberg 18 Dec '05

18 Dec '05

Hi. With NT, Windows did a Switch from INI-Files to the Registry and use "IniFileMapping" for compatibility with win9x-Apps. (see http://bugs.winehq.org/show_bug.cgi?id=4096) Wine is using both Methods when settings are changed (more code), and this introduce bugs if a Setting-Target is missing: (Example: http://bugs.winehq.org/show_bug.cgi?id=4097) Should we follow the Path of NT and implement the things around IniFileMapping to be compatible with every App that uses the API for INI-Files? We already do caching for INI-Files, so there is no additional incompatibility for very ugly Applications that modify INI-Files manual (open, read/write, close). -- By By ... ... Detlef

1 0

Re: DirectDraw over Direct3D
by Roderick Colenbrander 18 Dec '05

18 Dec '05

> > Second the required 3d functionality is VERY limited. Basicly the only > > thing the videocard needs support is texturing which all cards do. > > But that's obviously wrong - the video *driver* also needs to support it. > And the current 3D video driver situation in Linux is horrible. > Yeah linux drivers are crap for videocards from companies like S3/Via, XGI/Sis and also Intel. Most cards have some basic 3d driver support (the newer S3 ones not yet) but this basic support is enough. Texturing is something that is supported by all those basic drivers and cards. If your card can play Quake I it can also be used for the ddraw over direct3d renderer. A simple voodoo1 would even be fast enough (although this card can't do more than 16bit). The card also doesn't have to be fast. For instance your 2d game works at 800x600 and you use double buffering. You need to process half a million pixels for a single frame. That voodoo1 about which I talked already has a fillrate of 60MPixels so it can already do it fast enough. (one of the bottlenecks is the uploading of textures which happens through PCI / AGP / PCI-Express but this bottleneck appears for all drawing operations) Roderick -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie

2 1

Comparing a complicated program startup to windows
by Corey McClymonds 18 Dec '05

18 Dec '05

There is a game, known as Continuum, that has a very complicated setup before it actually starts the game, to prevent cheating. Due to this, the relay is very large, about 4MB, before it starts to repeat itself. I have gotten the +loaddll and the +seh logs at the bottom. I was just wondering, would it be possible to do the same startup on a Windows machine, and compare its relay to the relay from Wine. If this is possible, how would I go about this? Corey McClymonds

2 1

[wined3d] Converting Wined3d to use WGL instead of GLX
by Aric Cyr 17 Dec '05

17 Dec '05

Hello all, As I mentinoed in a recent post, I have almost completed the GLX->WGL conversion. Last night I tracked down my last bug that was causing most of my demo apps to fail. It seems that the problem was the conversion from glXGetProcAddress to using wglGetProcAddress. wined3d uses glXGetProcAddress to get the OpenGL extension function pointers, which is what wglGetProcAddress also does. However wglGetProcAddress _first_ checks opengl32.dll for the extension and returns the thunk function pointer if it exists, and only then falls back to libGL.so by calling glXGetProcAddress. So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d everything works fine, but then wined3d is still dependent on glx. So my questions: 1) should the thunks returned from wglGetProcAddress be causing crashes at all? Note that they don't crash right away, but "eventually" usually during a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). 2) what is the reason for wglGetProcAddress to check opengl32.dll before libGL.so? Would the reverse logic still be a resonable solution? Regards, Aric

7 13

Continuum Attached logs
by Corey McClymonds 17 Dec '05

17 Dec '05

Sorry about that, it would appear the logs aren't on the previous email of mine, so here they are. ----------------------------------------------------------- WINEDEBUG=+loaddll wine Continuum.exe trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\advapi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\gdi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\user32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "gdi.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "user.exe" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winex11.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\imm32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\iphlpapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\rpcrt4.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ole32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\shlwapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\comctl32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\shell32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\uxtheme.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ddraw.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ws2_32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wsock32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winmm.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\dsound.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winealsa.drv" : builtin ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) ALSA lib seq_hw.c:455:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msacm32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msacm.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\midimap.dll" : builtin -------------------------------------------- WINEDEBUG=+seh wine Continuum.exe trace:seh:__regs_RtlRaiseException code=80000003 flags=0 addr=0x7fc1fef0 trace:seh:__regs_RtlRaiseException eax=00000000 ebx=004c4050 ecx=004c4048 edx=004c405a esi=7bef4647 edi=004c4a4d trace:seh:__regs_RtlRaiseException ebp=000c1dd8 esp=7fc1fef0 cs=0073 ds=007b es=007b fs=1007 gs=0033 flags=00200246 trace:seh:__regs_RtlRaiseException code=c000001d flags=0 addr=0x4c40f2 trace:seh:__regs_RtlRaiseException eax=00000000 ebx=7bef01bc ecx=00000000 edx=bec35266 esi=7fc1fef4 edi=005283c2 trace:seh:__regs_RtlRaiseException ebp=000c1dd8 esp=7fc1fef4 cs=0073 ds=007b es=007b fs=1007 gs=0033 flags=00210202 ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) ALSA lib timer_hw.c:269:(snd_timer_hw_open) extended read is not supported (SNDRV_TIMER_IOCTL_TREAD) ALSA lib seq_hw.c:455:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory

2 1

SCREENSHOT: Windows Genuine Advantage 'GenuineCheck.exe' program generating key on Wine!
by Segin 17 Dec '05

17 Dec '05

The attached screenshot (UNMODIFIED) depicts the WGA 'GenuineCheck.exe' program that is used on the microsoft web site to 'validate' Windows so that you can download crap. Normally, it will not generate the needed key under Wine, but I have a screenshot (attached) of it doing so. I don't know is this is worth noting, as i couldn't tell you how I made it work (a LOT of things, too many to even count). However, I thought it might be something of intrest. If this is in any way useful to the development of Wine, please let me know.

2 1

Re: Create new mailing list wine-isv?
by Tony Lambregts 17 Dec '05

17 Dec '05

Jeremy White wrote: >>Not that I mean to sound like a pessimist, but I'm really just calling >>it as I see it. No offense to anyone intended. :) > > > This, in a nutshell, is Wine's greatest challenge > (stepping even outside ISV boundaries for a minute). > > I believe, either because I'm insane (the likely > explanation), or because it's true, that Wine has > progressed remarkably in the past 5 years, and can > no longer be correctly dismissed as unstable or unusable. > > I think the shift from Alpha to Beta status was a > more dramatic signal that anyone really realizes; > I think it marks the point where Wine can reliably > be used for a broad range of purposes. > > But, bluntly, we have to prove it. We have to start > by continuing the drive to a solid 1.0; we have to > continue helping a small number of ISVs really succeed. > > And then of course comes the fun part; we have to hold > that line and not let any regressions in :-/. <Rant> Well that is a real sore spot with me. You know that I am a strong supporter of wine but it really concerns me that we have gone beta and not addressed preventing regessions from getting into our releases in any way. We currently have no freeze or notification of exactly when the next release is going to go out. Sure we had the one big code freeze just before 0.9 but then we went back to releasing without any notification. At his point even if our application maintainers test their app every day there is no way for them to prevent that regression going into the next release. We had at least one known regression creep into 0.9.3. and maybe more that could have been corrected if we had some warning. I think that going to beta without any real attempt to provide even the most basic freeze release cycle is not a good thing. At the very minimum I would think that we should know when the releases are going to happen but we do not even know that. </Rant> > > But I think we can do it; it's why I'm still here. > Ditto. -- Tony Lambregts

5 7