June 2002 - Wine-Devel - list.winehq.org

Re: null midi device

by Eric Pouech

> I was thinking: Couldn't one use timidity to make a fake midi device > that actually produces sound? That would be something. I thought about it. you need to use timidity 0.20i (the last one from the original author released under LGPL, the next ones are released under GPL). Then, to make it a real midi driver (in terms of Win32 API) which isn't a trivial task (for example, timidity pre-processes the full content of the MIDI file to be played, whilst a standard MIDI driver has to play midi notes on the fly...). I did start looking at that a long time ago, but without real results in so far. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

June 6, 2002

Re: null midi device

by Johan Gill

I was thinking: Couldn't one use timidity to make a fake midi device that actually produces sound? That would be something.

June 6, 2002

imports by ordinal

by juergen.schmied＠debitel.net

Hi! 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? juergen

June 6, 2002

Need better documentation of Windows 16/32 APIs for Mingw Port

by Steven Edwards

Does anyone where I can find some good information on the win16/32 APIs? Any book refrences to amazon mabey? I'm trying to make a detailed list of what needs to be done to seperate all of the Wine 16/32 code and fix the locations of 16bit api call importations and it is turning in to a PITA. Finding anything on the normal APIs in MSDN is gettin harder everyday with all of the .NET crap they keep adding and the fact they tend to have a lot of bugs in there own docs. I will be submitting a few issues to bugzilla and emailing wine-devel this weekend with all of the TODO for proper seperation. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 6, 2002

Re: self-registerable standard DLLs

by Steven Edwards

> Despite this, is it > generally acceptable to have actual code to > register/unregister a standard > COM server DLL in its Dll[Un]RegisterServer? It > would be redundant for > normal Wine, but hey, it's not big or complex. If you could implement this it would rock as I need it for the Mingw port and Patrik will need it for his VC++ port. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 6, 2002

Re: How big is the Direct3D stuff?

by Francois Gouget

On 5 Jun 2002, Chris wrote: > I could be totally wrong here, but if I understand the current situation > correctly, I don't think we'll be receiving DirectX 8 anytime soon from > Transgaming ... [...] I agree. This is why it we should start organizing and mapping the work to do. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

June 6, 2002

Re: How big is the Direct3D stuff?

by Chris

I could be totally wrong here, but if I understand the current situation correctly, I don't think we'll be receiving DirectX 8 anytime soon from Transgaming ... I mean, I read they might be sharing code that helps out InstallShield and sdldrv and that sort of stuff, but ... why don't we pick it up for the winehq.com tree? I think we should develop D3D. The MSDN has excellent docs has to how various DirectX 8 functions work, so it's not like we're in the dark here. Okay, that's my two cents. On Wed, 2002-06-05 at 21:31, Francois Gouget wrote: > On Wed, 5 Jun 2002, Roland wrote: > > > 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? > > It would be interesting to have tasks concerning DirectX in Bugzilla. > especially if things like Direct3D can be broken up into reasonably > independent and smaller items. So my questions would be: > > * What are the tasks for implementing Direct3D? > * Can older versions be implemented independently from the newer ones? > * Do we have nothing at all or do we have something? What changes need > to be done to this something to make it better. > * What modifications are necessary to other parts (x11drv, DirectDraw) > to implement Direct3D? > * Are there other DirectX areas that are lacking and that will prevent > games from working even if we get Direct3D working (DirectPlay, > DirectInput)? > * One item I can suggest is adding support for XVideo to DirectDraw (I > believe that's where it fits) to enable hardware scaling and YUV > conversion when playing videos. This would be more for media players > than games but could be useful anyway. > > Any expert willing to shed light? > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > 145 = 1! + 4! + 5! > > -- Chris chris(a)luethy.net

June 6, 2002

Bug 586

by admiral coeyman

Before retiring this bug with a patch, I have to check some things with somebody who knows the memory functions used in DOS emulation. I got the return address using CTX_SEG_OFF_TO_LIN on SegSs and Eip. Then, I used DOSMEM_MapDosToLinear on the return of DOSMEM_MapRealToLinear( (DWORD)*retpointer ) where retpointer is the result of the CTX call. I'm hoping that this gave me the linear address of the return address. Backup once, write a NOP ( 00 ) Backup again and write the 0x9b wait instruction. That should overwrite the interrupt call. Then, I have to back the return address up two bytes, to execute this code. Since my code pointer points to the first byte that I changed, I used DOSMEM_MapLinearToDos((LPVOID *)codepointer) and stored that value in *retpointer. Do these functions do what I think that they do and did I get my offsets right? If I got all of this right, I'll be able to complete the rest of these emulation interrupts, assuming an FPU is installed. There is one thing that bothers me. My resources say that this emulation code is part of the programs that use it. I don't have this program to test with. God Bless, --Admiral Coeyman -- --- May you live as long as you wish and age but a single day. http://www.dotguy.net/ admiral(a)corner.net Webmaster/ Linux Administrator Computer Co-Op/CornerNet

June 6, 2002

Re: How big is the Direct3D stuff?

by Francois Gouget

On Wed, 5 Jun 2002, Roland wrote: > 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? It would be interesting to have tasks concerning DirectX in Bugzilla. especially if things like Direct3D can be broken up into reasonably independent and smaller items. So my questions would be: * What are the tasks for implementing Direct3D? * Can older versions be implemented independently from the newer ones? * Do we have nothing at all or do we have something? What changes need to be done to this something to make it better. * What modifications are necessary to other parts (x11drv, DirectDraw) to implement Direct3D? * Are there other DirectX areas that are lacking and that will prevent games from working even if we get Direct3D working (DirectPlay, DirectInput)? * One item I can suggest is adding support for XVideo to DirectDraw (I believe that's where it fits) to enable hardware scaling and YUV conversion when playing videos. This would be more for media players than games but could be useful anyway. Any expert willing to shed light? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

June 5, 2002

self-registerable standard DLLs

by John K. Hohm

I noticed that the attempt to test comcat.dll on Win98 failed because DllRegisterServer is a stub returning E_NOTIMPL. I have added the registry entries for the component categories manager to winedefault.reg, which should suffice for normal Wine installations. Despite this, is it generally acceptable to have actual code to register/unregister a standard COM server DLL in its Dll[Un]RegisterServer? It would be redundant for normal Wine, but hey, it's not big or complex.

June 5, 2002

Re: PATCH: [Bug 671] Valve Hammer Editor does not run - recursion in buddySupperClassWndProc

by Guy L. Albertelli

----- Original Message ----- From: "Dimitrie O. Paun" <dpaun(a)rogers.com> To: <wine-devel(a)winehq.com>; "Guy L. Albertelli" <galberte(a)neo.lrun.com> Sent: Wednesday, June 05, 2002 12:48 AM Subject: Re: PATCH: [Bug 671] Valve Hammer Editor does not run - recursion in buddySupperClassWndProc > On June 5, 2002 12:31 am, Guy L. Albertelli wrote: > > Ok, the loop was due to constant setting of the buddy wndproc because the > > retrieve of the wndproc did not match. The match failed because the > > application > > program added a wndproc (its own) to the buddy window. The fix will be > > submitted to wine-patches. > > Hmm, I see. But with this fix, it means that you can not change the > wndproc of the buddy once set. This can not be right... Also, you > broke the UDM_SETBUDDY. > > I this the correct fix is to add the flag as a property on the buddy, > not on the UpDown... You probably are correct, Dimi. What I did is model the builtin actions on what the +relay,+message trace of the native showed. The basic problem was that the GetWindowLong never returned the builtin wndproc address, so we always did the SetWindowLong again. This disabled the application's own wndproc and eventually caused the loop. Since the native control never did the GetWindowLong and did the SetWindowLong only once, that was how I changed the code. It sounds like you have a much better understanding of UpDown (and probably some better test cases). Please correct my poor attempt. Thanks, Guy

June 5, 2002

How big is the Direct3D stuff?

by Roland

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

June 5, 2002

Re: Asymmetric mouse movement in DGA2 mode

by J. Christopher Pereira

On Tue, 2002-06-04 at 11:01, Vincent Béron wrote: > "J. Christopher Pereira" a écrit : > > > > System: latest winex CVS version + XFree86 4.2.0 > > Since you're using WineX, please report to it to Transgaming. > OTOH, you can try the latest Wine CVS (from winehq.com) and if your > issue is also present in it, then report it. The same goes for wine. I downloaded the latest wine CVS from winehq and patched 'dlls/x11drv/event.c' for processing mouse + keyboard events in DGA mode. The movement is still asymmetric :-(

June 5, 2002

Re: winebootup

by Andreas Mohr

On Tue, Jun 04, 2002 at 10:52:07PM -0500, Jeremy White wrote: > Hetz Ben Hamo wrote: > > >I've seen in the crossover office that there is a reboot.so file, but I think > >thats codeweaver's closed source part since it's not part of wine itself (if > >I'm not mistaken) > > > > Well, when we were hip deep in preparation for CrossOver Office, > Andreas had just started doing a full set of boot processing logic. > I had a conversation with Andreas about it; convinced that his was > the 'right' approach, but that it wouldn't be ready soon enough for us, > we hacked together something quick and dirty. > > The idea was that Andreas was to have been done by now, hint, hint <grin>. > > Andi? /me better won't reveal his feelings now :-\ I'm attaching the current implementation of programs/wineboot. I removed all GUI code and made sure that it still works, but it's not fully ready yet, I think (configuration settings, for example). I always planned to finish it, but with 50 mails in my "reply" queue and Linuxtag looming, the prospects for this are a bit grim at the moment... Also, I feel that I'm still a bit unsure as to how exactly it should be implemented: - how exactly are we going to check for new "bootup" entries to be processed ? - when exactly would it be run - etc. etc. In case someone wants to work on it, feel free. Otherwise I'll continue to work on it when I've got a lot more free time, i.e. in August/September. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

June 5, 2002

Re: Making a patch

by Andriy Palamarchuk

Hi Nix N. Nix, --- "Nix N. Nix" <nix(a)go-nix.ca> wrote: > I have implemented the RunFileDlg in shell32.dll, > but I don't know how > to make a patch and submit it to wine-patches. > Well, I have a pretty > good idea, but I don't want to submit a garbage > patch. Can you please > help me ? Described in details here: http://www.winehq.com/development/#patches Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 5, 2002

Making a patch

by Nix N. Nix

I have implemented the RunFileDlg in shell32.dll, but I don't know how to make a patch and submit it to wine-patches. Well, I have a pretty good idea, but I don't want to submit a garbage patch. Can you please help me ? Thanks.

June 5, 2002

Re: Call for application owner

by Andriy Palamarchuk

--- "Guy L. Albertelli" <galberte(a)neo.lrun.com> wrote: > Having just fixed Bug 671, I think we need an owner > for the Valve Hammer > application. It demonstrates numerous bugs on the > CVS version (4 days old). > The bugs range from LoadLibrary errors during the > installer run, to gui > problems with the main screen. Even the tab control > demonstrates differences > from native in this package. > > I don't have the time to use this program as a test > base and hope someone > can step up and do it. I'm not going to be an application owner in the full sense of this word, but I can submit bugs which I'll found on the surface ;-) I'll reopen the bug and reassign to myself, so I won't forget it. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 5, 2002

Re: PATCH: [Bug 671] Valve Hammer Editor does not run - recursion in buddySupperClassWndProc

by Dimitrie O. Paun

On June 5, 2002 12:31 am, Guy L. Albertelli wrote: > Ok, the loop was due to constant setting of the buddy wndproc because the > retrieve of the wndproc did not match. The match failed because the > application > program added a wndproc (its own) to the buddy window. The fix will be > submitted to wine-patches. Hmm, I see. But with this fix, it means that you can not change the wndproc of the buddy once set. This can not be right... Also, you broke the UDM_SETBUDDY. I this the correct fix is to add the flag as a property on the buddy, not on the UpDown... -- Dimi.

June 4, 2002

WINE dlls on Windows Status Update

by Steven Edwards

As many of you know, I have been in the process of porting the WINE shared libraries to Mingw as Windows PE dlls for the ReactOS project. Below are results of testing the dlls that we can build from the current WINE tree under Windows98SE. We were going to use win2k for this test however the Windows File Protection was giving us to much trouble for it to be worth it at this time. Another test is planned at the end of the month using win2k. Thanks to Chris Gianelloni for helping to setup and run these test in VMware. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson comcat.dll Win98 Test - Load of DllRegisterServer failed comctl32.dll Win98 test - shell32 imports ImageList_Read from comctl32.dll (kills 98 bootup) crtdll.dll Not Tested - Forwarder to Msvcrt crypt32.dll Not Tested - Stubbed Dll dciman32.dll Not Tested - Stubbed Dll dinput.dll Joy.cpl would not load in control panel dplayx.dll dxdiag.exe - Failure at step 2 (Creating Direct PLay object):HRESULT=0x80040154 (CLASS NOT REGISTERED) imagehlp.dll IE works , Outlook Express starts very slowly Check this =P http://service2.symantec.com/SUPPORT/nav.nsf/docid/2000011214501806 imm32.dll Stubbed Dll no problems but nothing to test with mapi32.dll If Outlook Express uses it then its fine. we replaced mapi32,mapi32x and mapi32s stub and it worked with hotmail and pop/imap. msdos prompt appears to be lined to mapi32.dll =P mpr.dll Didnt ask to login, Network Neigborhood is GONE, setupapi.dll is linked to missing export in mpr.dll:WNetCancelConnection2A error loading powerprof.dll a device attached to this system is not functioning. When trying to browse a smb network \\192.168.0.250 Error the network request is not supported msdmo.dll Not Tested as blank msimg32.dll Not Tested - Stubbed Dll msisys.ocx msinfo.exe loads and works. netapi32.dll FileSharing works. odbc32.dll Not Tested oleaut32.dll You cant view as a web Page in My Computer. If disable View as Web Page everything works fine oledlg.dll Nothing wrong but Stubbed Dll olepro32.dll Not Tested - Stubbed Dll rasapi32.dll No test as no modem at current riched32.dll Tested Win98 - Outlook Express, Networking, IE all flawless. serialui.dll No tested as no modem at current shdocvw.dll General Protection Fault - Explorer.exe shlwapi.dll Shell32 missing export from shlwapi SHRegGetUSValueA (kills 98 bootup) tapi32.dll No test as no modem at current twain_32.dll Not tested No Scanner to test with at this time. urlmon.dll Kills MSHTML. No Error. IE just doesnt work. Neither does View as Web Page crap. Forgot to test Outlook Express winnls.dll Not Tested - Stubbed Dll winspool.drv Error twice loading powerprof.dll - A device attached to the system is not functioning setupapi dll is linked to missing exported Winspool.drv:GetPrinterDriverDirectoryA the vmcontrolpanel.cpl is linked to missing export Winspool.drv:OpenPrinterA wintrust.dll Not Tested - Stubbed Dll

June 4, 2002

Call for application owner

by Guy L. Albertelli

Having just fixed Bug 671, I think we need an owner for the Valve Hammer application. It demonstrates numerous bugs on the CVS version (4 days old). The bugs range from LoadLibrary errors during the installer run, to gui problems with the main screen. Even the tab control demonstrates differences from native in this package. I don't have the time to use this program as a test base and hope someone can step up and do it. The installer is the second attachment to Bug 671 and is all you need to get started. Guy Albertelli <<galberte(a)neo.lrun.com>>

June 4, 2002

Re: winebootup

by Jeremy White

Hetz Ben Hamo wrote: >I've seen in the crossover office that there is a reboot.so file, but I think >thats codeweaver's closed source part since it's not part of wine itself (if >I'm not mistaken) > Well, when we were hip deep in preparation for CrossOver Office, Andreas had just started doing a full set of boot processing logic. I had a conversation with Andreas about it; convinced that his was the 'right' approach, but that it wouldn't be ready soon enough for us, we hacked together something quick and dirty. The idea was that Andreas was to have been done by now, hint, hint <grin>. Andi? Cheers, Jer

June 4, 2002

Re: Lower bugs changing note

by Francois Gouget

On Tue, 28 May 2002, Andriy Palamarchuk wrote: > > --- Dustin Navea <speeddymon(a)yahoo.com> wrote: > > The changes on the lower numbered bugs are done by > > me, > > trying to get some of these old bugs out of he list > > of > > ones to be worked on, if they have been fixed..... > > I noticed :-) Me too. Especially since I reported quite a few old bugs :-) > Dustin, > thank you for the great work you do. It was long > overdue to clean these old issues. I agree 100% You, Andryi and Tony are doing a great and much needed job with the bug database. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

June 4, 2002

Re: FW: WINE with MFC and C++ DLLs (Was: Info on porting Wine dlls and programs to Mingw)

by Francois Gouget

On Fri, 31 May 2002, Steven Edwards wrote: > In case anyone is interested in a alternitive to winemaker. Thanks. I don't think that these scripts will be usable directly with Wine but they are interesting nonetheless. I added the links to bug 61 - 'winemaker: Add support for the Visual C++ project files'. http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=61 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

June 4, 2002

Re: Improving debugging (gdb) support

by Ulrich Weigand

Michael Cardenas wrote: > Ont major problem is that gdb doesn't understand wine's handling of > windows threads, even if it does understand the windows pe format. It would appear I was a little too pessimistic here; while gdb does indeed not understand win32 threads directy, when using the remote debugging stub API, it looks like it is possible for the stub to tell gdb everything it needs to know about threads. That would mean that it should be possible to write a remote debugging stub that uses the Win32 API to inform gdb about everything related to win32 threads ... > Ulrich, you want to post your presentation here? Didn't you want to put those up on your website? It's probably a bit large for the list ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

June 4, 2002

RE: Clear up my License information

by Patrik Stridvall

> > So no, save the work nessessary for Rewind to make any patch > > from X11 licenser apply I don't see any problem from LGPL > > "contamintion" of the patches. In any case, as I said earlier > > this is Rewind problem, not the X11 licenser. > > Ok If its ReWinds problem that's cool. Yes. :-) > Are you still planning on doing any work porting the Wine > dlls to MS_VC? Yes. I haven't felt like working with the previous weeks though. > I could use some help seperating the win16 code from the ones I have > left. OK. I will see what I can do. First on my priority list is cleaning up and releasing the Microsoft Visual C project files generator though. One of Alexandre's Makefile changes broke it and I haven't taken time fixing it yet...

June 4, 2002