Re: Final call for bug fixes (insert , after DEL)
Am Freitag, den 21.10.2005, 15:09 +0200 schrieb Alexandre Julliard: So if you have bugs that you feel must be fixed for 0.9 (and that can be fixed with minimal changes), now is the time to speak up... Has someone a fix for the DEL-Key while NumLock is active - Problem? (inserting a , after deleting the character right from the cursor) -- By By ... ... Detlef
Roadblock #1 for VB installers: MDAC
A lot of VB apps use MDAC (http://msdn.microsoft.com/data/mdac/downloads/). They tend to include mdac_typ.exe, the mdac installer, and run it, but unfortunately, Wine doesn't seem to run it properly. (I'm testing using mdac 2.7 sp1, fwiw.) First, the MDAC installer refuses to run unless the registry key for IE6 is present. (OK, that's easy to work around... if you're a programmer. It probably ought to be a winecfg pulldown.) Second, even if the MDAC installer runs, all it does is install a bunch of directories under c:\windows\RegisteredPackages. The DLLs needed by the VB app are locked up in .cab's in those directories. In the app I'm trying to install, the installer then fails with err:module:import_dll Library MSDART.DLL (which is needed by LC:\\windows\\system32\\msadox.dll) not found Something, somehow, is supposed to be triggering an unpack, but it's not happening. (See http://msdn.microsoft.com/workshop/delivery/download/download_node_entry.asp for a discusion of how the unpacking is supposed to go on Windows.) I've filed a bug report at http://bugs.winehq.org/show_bug.cgi?id=3636
Re: GDI/tests: link to {G|S}etRelAbs() during runtime
On Fri, Oct 21, 2005 at 01:06:48PM +0300, Saulius Krasuckas wrote: +hGDI = LoadLibraryA(gdi.dll); You mean gdi32.dll -- Huw Davies [EMAIL PROTECTED]
Wine project: Support third party LDDM graphic drivers
hello all, don't bother on this message if you feel it has nothing to be here. But I rencently read a whole lot of MSDN documentation about the LDDM infrastructure. The new Windows graphics vista driver model. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Display_d/hh/Display_d/DisplayDriverModel_Guide_c96d975e-dcc9-49b5-be73-b4d8b9f06eb8.xml.asp And what made me think we could have support for it in linux. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Display_d/hh/Display_d/DisplayDriverModel_Guide_c96d975e-dcc9-49b5-be73-b4d8b9f06eb8.xml.asp It seem to me that having the most important parts of the driver being in user mode would really help to use it on other systems. From what I read, the user mode driver would create the command buffer that would need to be uploaded to the GPU and a kernel module would need to schedule GPU access handle memory of the GPU and send the command buffer to it. This would need the Wine Expertise of DirectX reimplementation as well as some good kernel hacker, but in the end maybe the struggle to have linux specific support from Graphics adapter vendors could be one for all removed if we had LDDM driver support and then and X build on top of it (same philosofy as Xgl). it could also benefit to the wine project itself as we would have really windows driver being used, it should help to increase compatibility. sorry if it sound crazy...
Cannot compile 20050830 on Solaris 9
Ok, Im almost there (or at least alot closer). After editing a source file and a few Makefiles and manually applying several diffs from Robert Lunnons patchkit from different Wine versions (none applicable to 20050830). I got Wine to compile on Solaris 9! Now when running wine, it sits for a few seconds, then spits the following error and quits: try_mmap_fixed: vfork: Resource temporarily unavailable I found this is coming from /lib/mmap.c after a call to vfork. There is nothing in the call that strikes me as odd, nor any indication in the man page for vfork, why it would be temporarily unavailable. The man page only specifies 2 failure modes. ENOMEM indicates there is no swap space for the new process. The machine has 512MB of RAM, and 800MB swap partition is only 1% used, so that is unlikely. The other failure mode (EAGAIN), is even less likely if I understand correctly. It mentions that the user limit for processes has been exceeded. I doubt this is likely, even with 2-3 xterms open on each of 3 monitors, but I closed all but 1 and tried executing as root, with no success. Thanks in advance, Rob Stuck again Done
Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back
Mike Hearn schrieb: On Wed, 12 Oct 2005 21:16:05 +, Eddahbi Karim wrote: Now the mouse problem comes back but the workarounds don't work this time. It's not a regression, it's a bug enhancement. ACK The old workaround for WineX still work according to gentoo-forums [2]. It seems Warcraft relies upon NULL-addressed VirtualAlloc starting allocation from above a certain range - possibly they're pulling some silly bit-twiddling hack or optimisation. The Cedega patch linked to on the forums basically hints to mmap that it should allocate at a fixed address in this case: http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html I tried that logic with the mmap wrapper but that did not help ... with and without printf. I'm just wondering of this code because start address must be a multiple of pagesize. WoW allocs sometimes less ... like 2 or 178 bytes. Which for WoW they seem to set this hint to 256mb - is there some aspect of the NT kernel we're not correctly implementing here? Does Windows always allocate from 256mb upwards? Alexandre, Mike - does hinting to mmap in the port library as TransGaming do it seem like a good solution here or would it be better to adapt the preloader to block off the lowest $X megs? I'm away for a week so I dont have time to hack and test this into wine ... and I have no time for gaming either :-/ chris thanks -mike
wine FC package [was: Final call for bug fixes]
hi, I have build a FC4 rpm package adapting the MDK spec file and patches. All the files can be found here: http://magisystem.yi.org/rpms/ I hope that it can help... Regards, Paolo Abeni -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Audio, Video, HI-FI...oltre 2.000 prodotti di alta qualità a prezzi da sogno solo su Visualdream.it Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2954d=21-10
Caching for X11DRV_SetImageBits?
Let me start off with an introduction. I'm a veteran C programmer, but I'm unfamiliar with programming X11 and unfamiliar with wine, although I've been looking into both recently to correct a problem I'm having with wine. I posted about the same problem in August on the same mailing list, about making function parameters const. This was a simplistic solution, but I suggested it simply because I didn't feel I had the time to familiarize myself with all the inner-workings of wine. Now, I believe I do have the time. To repeat the situation, I found that in several of the games I like to run, the same problem is causing wine to be slow: using oprofile, I find that nearly all of wine's CPU usage lies in x11drv, and 98-99% of the cpu usage in x11drv is taken up by calls to some of the convert functions in dib_convert.c. For example, in Civilization 3, some 98% of the CPU usage in x11drv is taken up by two functions: convert_555_to_565_asis, and convert_565_to_555_asis. This summer I had a similar problem on my laptop, where fce ultra was using the function convert_888_to_0888_asis for most of its cpu. Essentially, it seems that most of the work wine is doing when running these programs is just for converting between one pixel format and back, and I hope to find a good solution to this speed problem, preferably through caching. I'm writing to this list in hope of other more experienced wine hackers giving their advice, telling me what is possible, and what the best solution is, before I go too far on my own with this. I'm looking at a group of related functions in wine, in dlls/x11drv/dib.c. It came to my attention that in X11DRV_SetDIBits and X11DRV_SetDIBitsToDevice, wine always seems to end up calling X11DRV_DIB_SetImageBits, which calls (in my case, probably because my desktop is 16-bit color) X11DRV_DIB_SetImageBits_16, which in every case calls a convert function of one type or another (all of which are CPU hogs). These are the core functions that seem to be related to the problem. Here is my early analysis of the problem: X11DRV_DIB_SetImageBits always creates and destroys an XImage during the life of the function, and calls X11DRV_DIB_SetImageBits_16 (or another bit depth), which ends up converting the bitmap to the proper color format / bit depth. It seems to me the best solution is to use some kind of caching to save the converted bitmap in its cached form, preferably as an XImage. Inside X_PHYSBITMAP the HBITMAP is stored, windows' unique handle for that particular bitmap. So, what if we stored the appropriate converted XImage per-HBITMAP, per-bpp, so that it doesn't need to be created, converted, and destroyed each time, and we could delete all cached XImages corresponding to the HBITMAP from the cache when DeleteObject() is called for that HBITMAP? I'm doing a lot of guesswork on the inner-workings of wine, X, and the windows GDI here. Please tell me, am I on the right track for eliminating these unnecessary conversions? If not, where should I be looking? Again I'm new to wine, X, and somewhat new to GDI programming - but I would like to learn. Please, GDI/X11 experts, give me some advice on the best solution to this problem!
Re: bug 2398: OpenGL, child windows, and wine
Hello, Dan Kegel wrote: he suggests using the new GL_EXT_framebuffer_object OpenGL extension. I checked around a bit, and it appears to be at least partly supported by the latest NVidia and ATI drivers. I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway. I want to point out that there are other applications like my Diamond (bug 2315, duplicate of 2320; Diamond is a crystal structure viewer), which are definitly also run on weaker hardware. And at least a glxinfo |grep -i GL_EXT_frame does not return anything on my Laptop (IBM (ATI Radeon) RV250 Lf). Maybe some solution which works on both high-end systems and on a bit older systems would be useful. (Implementing maybe conditionally GL_EXT_framebuffer_object and the work around?) Tobias PS: Diamond screen shots: http://www.crystalimpact.com/diamond/ (Windows w/ openGL) http://appdb.winehq.org/screenshots.php?appId=1307versionId= (Wine, no openGL)
Re: Downloading Mozilla ActiveX
Vincent Béron wrote: Le mar 18/10/2005 à 18:31, Jonathan Ernst a écrit : Le mardi 18 octobre 2005 à 11:38 -0600, Brian Vincent a écrit : On 10/18/05, Vitaliy Margolen [EMAIL PROTECTED] wrote: Does that server has enough capacity to handle all Wine users? Will it be there for a long time? No idea about capacity, but the URL hasn't changed in years. We could take a clue from Codeweavers and put in a winehq.org URL that simply redirects to that one. If it changes we just update our redirect. -Brian I really think it's the way to go. That doesn't solve the capacity problem (which was a real one the last time this discussion occured, and is the reason why the address is not in wine.inf). Newman wasn't very fond of hosting it on winehq either. Sourceforge looked like the best place regarding capacity, but the automatic download part is a problem with it (unless we put it on our webspace over there, but I'm not sure if it'd be Ok with their TOS). Vincent . For capacity, why not use Coral Cache? Just link to http://www.iol.ie.nyud.net:8090/~locka/mozilla/MozillaControl16.exe --mmebane -- I find that a great part of the information I have was acquired by looking up something and finding something else on the way. -- Franklin P. Adams
compile wine with icc
anyone already tried that? I'm getting some errors when compiling wine which I was able to fix, but World of Warcraft won't start... Will icc be supported at some time in the furure? tom
New themes question
Now that Wine supports different theme packs for Windows, would it be possible to render Windows widgets using the native current desktop KDE/Gnome theme? Also other stuff like font size, name and colors for Windows widgets, could they all be unified? That would *really* be something:). Big thanks to all developers, that drove Wine so far and best wishes for the future! - Matevž signature.asc Description: OpenPGP digital signature
Re: [PATCH] wined3d VideoRam registry setting
Am Mon, 17 Oct 2005 00:17:22 +0200 schrieb Fabian Bieler [EMAIL PROTECTED]: On Sunday 16 October 2005 23:34, Fabian Bieler wrote: OK, here I go again: This is a small C program which should get the videoRam using the NV-CONTROL and ATIFGLEXTENSION extensions. As I only have a nVidia card, could someone with an ATI card (and the fglrx driver) please test this? Fabian this time with one bug less... ;-) I have tried your program with my ATI card and it says videoRam: 2048 kBytes. It should be VideoRAM: 131072 kByte like Xorg.log says. I think there is a bug in your program. Lukas
Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back
Mike Hearn mh at codeweavers.com writes: On Wed, 12 Oct 2005 21:16:05 +, Eddahbi Karim wrote: Now the mouse problem comes back but the workarounds don't work this time. It's not a regression, it's a bug enhancement. The old workaround for WineX still work according to gentoo-forums [2]. It seems Warcraft relies upon NULL-addressed VirtualAlloc starting allocation from above a certain range - possibly they're pulling some silly bit-twiddling hack or optimisation. The Cedega patch linked to on the forums basically hints to mmap that it should allocate at a fixed address in this case: http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html Which for WoW they seem to set this hint to 256mb - is there some aspect of the NT kernel we're not correctly implementing here? Does Windows always allocate from 256mb upwards? The weird thing here, IMHO, is that the old workaround like switching to 2.6.12 kernels (which did the trick for me), using some hacked preloaders (which didn't do the trick for me) and all [1] don't work this time. Only the Cedega fix *seems* to work (According to *one* post on the gentoo forum [2]) If you want some debugging informations, just give me the way to look for them and I'll give them. thanks -mike -- Notes : [1] http://forums.gentoo.org/viewtopic-t-390127.html [2] http://forums.gentoo.org/viewtopic-p-2794128.html#2794128 -- Eddahbi Karim [EMAIL PROTECTED] Freelance
Re: shell32: Remove redundant .\\ from test files
James Hawkins wrote:
Hi,
I started by removing all .\\ from the shlfileop.c test file in msvc
and the tests all passed , but three of the tests failed in wine.
If the tests fail on wine, should they not be todo_wine{} then?
regards,
Jakob
preload libGL
I need to preload my own library with a custom glXSwapBuffers(). But wine opengl libGL.so directly so there's no way to do it. I've ended up doing this: glXSwapBuffersType preload__glXSwapBuffers = (glXSwapBuffersType) wine_dlsym(RTLD_DEFAULT, glXSwapBuffers, NULL, 0); preload__glXSwapBuffers(gdi_display, physDev-drawable); but that is not a nice solution. What about linking x11drv directly with libGL? tom
Re: Fix for #3464
Can I create b: on the fly, allocate 1.44 megabyte RAM, do all copies
there and then
copy it back?
Am I on crack?
regards,
Jakob
Eric Pouech wrote:
It turns out that DOS' ioctl 0x440F (set logical drive map) was
strangely implemented. From the doc I have, this ioctl is responsible
for setting the logical drive to access a physical drive. This is used
for example, on a single floppy PC when implementing the copy a:foo
b:bar command, where a: and b: refer to the same physical device (the
floppy), and this ioctl is called to toggle the access from a: or b:
to the physical device.
This implies that this ioctl is not responsible for creating the
mapping of a: and b: to the same physical device.
The current implementation was trying to achieve this goal and
moreover it was done in the wrong way :-/
The attached patch removes altogether the support for logical drive
map in int21h (and fixed Myst BTW).
A+
Name: int21_mapdrv
ChangeLog: ioctl 440F only returns non mapped drives (for now)
License: X11
GenDate: 2005/10/12 18:41:20 UTC
ModifiedFiles: dlls/winedos/int21.c
AddedFiles:
RemovedFiles:
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/winedos/int21.c,v
retrieving revision 1.81
diff -u -u -r1.81 int21.c
--- dlls/winedos/int21.c18 Sep 2005 11:11:36 - 1.81
+++ dlls/winedos/int21.c12 Oct 2005 18:40:47 -
@@ -2627,19 +2627,12 @@
break;
case 0x0f: /* SET LOGICAL DRIVE MAP */
-{
-WCHAR dev[3], tgt[4];
+TRACE(IOCTL - SET LOGICAL DRIVE MAP for drive %s\n,
+ INT21_DriveName( BL_reg(context)));
-TRACE(IOCTL - SET LOGICAL DRIVE MAP for drive %s\n,
- INT21_DriveName( BL_reg(context)));
-dev[0] = 'A' + drive; dev[1] = ':'; dev[2] = 0;
-tgt[0] = 'A' + drive + 1; tgt[1] = ':'; tgt[2] = '\\'; tgt[3] = 0;
-if (!DefineDosDeviceW(DDD_RAW_TARGET_PATH, dev, tgt))
- {
- SET_CFLAG(context);
- SET_AX( context, 0x000F ); /* invalid drive */
- }
-}
+/* FIXME: as of today, we don't support logical drive mapping...
+ */
+SET_AL( context, 0 );
break;
case 0x11: /* QUERY GENERIC IOCTL CAPABILITY */
Re: button.c: misplacement of checkboxes with empty label fixed, found one mistypo...
Hi Markus,
Please send patches included as in-line text (being careful to avoid
line-wraps). This helps for reviewing patches.
The changelog entry normally goes before the patch, not included as part of
the patch.
Cheers,
Paul.
On Wednesday 19 Oct 2005 12:18, you wrote:
dlls/user/button.c: Misplacement of checkboxes with empty label fixed,
found one mistypo...
Markus Gömmel
[EMAIL PROTECTED]
PS: This is my first patch, so please let me know if I did something
wrong...
begin 666 patch.diff
M/R!O=70*/R!P871C:YD:69F[EMAIL PROTECTED]]T86PM,#4Q,[EMAIL PROTECTED]
M($-H86YG94QO9PH]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]E)#4R!F:6QE.B O
M:]M92]W:6YE+W=I;F4O0VAA;F=E3]G+'8*F5TFEE=FEN9R!R979IVEO
M;B Q+CDX[EMAIL PROTECTED]@[EMAIL PROTECTED] @+7(Q+CDX([EMAIL PROTECTED]
M;F=E3]G3,P(%-E R,# U(#$R.C R.C,X(TP,# P[EMAIL PROTECTED]($-H
M86YG94QO9PDQ.!/8W0@,C P-2 Q-CHQ,#HU-2 M,# P, I 0 M,2PS(LQ
M+#@0$ **PHK[EMAIL PROTECTED]QLR]UV5R+V)U='1O;BYC.B!-87)K=7,@1V]E;6UE
M; \;2YG;V5M;65L0-O;7!U;%B+F1E/@HK4UIW!L86-E;65N=!O9B!C
M:5C:V)O5S('=I=@@96UP='D@;[EMAIL PROTECTED]@+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+0H@,C P-2TP.2TS, @06QE%N9')E($IU;QI87)D( \
M:G5L;EAF1 =VEN96AQ+F-O;3X*( I);F1E[EMAIL PROTECTED]QLR]UV5R+V)U='1O
M;BYCCT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T*4D-3(9I;4Z(]H;VUE+W=I
M;F4O=VEN92]D;QS+W5S97(O8G5T=]N+F,[EMAIL PROTECTED]:65V:6YG(')E=FES
M:6]N(#$N.0ID:69F(UU(UU(UP(UR,2XY()U='1O;BYCBTM+2!D;QS
M+W5S97(O8G5T=]N+F,),3(@4V5P(#(P,#4@,3(Z,C Z,S@@+3 P,# ),2XY
MBLK*R!D;QS+W5S97(O8G5T=]N+F,),3@@3V-T(#(P,#4@,38Z,3 Z-3@
M+3 P,# *0$ @+3DQ-PX(LY,30L,3,@0$ @W1A=EC('9O:[EMAIL PROTECTED])?4%I
M;G0H($A73D0@:'=N9[EMAIL PROTECTED](A$0PH@( @(-L:65N= ](')T97AT.PH@
M( @(1T1FQA9W,@/2!55143TY?0V%L8TQA8F5L4F5C=AH=VYD+!H1$,L
M(9R=5X=D[B @( @BT@( @F)OYT;W @/2!R=5X=YT;W [BT@
M( @F)OYB;W1T;VT@/2!R=5X=YB;W1T;VT[BL@( @[EMAIL PROTECTED]2!A
M9IUW0@F)O!W:5N(')T97AT(ES('9A;ED(HOBL@( @:[EMAIL PROTECTED]1T
M1FQA9W,@([EMAIL PROTECTED])3E0I+3%,*0HK( @('L**PER8F]X+G1O ](')T97AT
M+G1O#L**PER8F]X+F)O='1O;2 ](')T97AT+F)O='1O;3L**R @(!]BL*
M( @( O*B!$F%W('1H92!C:5C:RUB;W@@8FET;6%P(HOB @( @:68@
M*%C=EO;B ]/2!/1$%?1%)!5T5.5$E212!\?!A8W1I;VX@/[EMAIL PROTECTED]
M3$5#5D*( @(B
M;[EMAIL PROTECTED]]M([EMAIL PROTECTED];WA(96EG:'0[B )( @('[EMAIL
PROTECTED]B )
M7)B;[EMAIL PROTECTED]]M(L](UD96QT82\R(L@,3L*+0D)F)OYT;W @/2!R
M8F]X+F)O='1O;2 M/2!C:5C:T)O$AE:6=H=#L**PD)F)OYT;W @/2!R
M8F]X+F)O='1O;2 M(-H96-K0F]X25I9VAT.PH@2 @(!]B )?2!E;'-E
H('[EMAIL PROTECTED]@15F875L= J+PH@2 @(!I9B H95L=$@/B P*2![@``
`
end
pgpXiRgcZIBMy.pgp
Description: PGP signature
The program crashes after start
Hi to all, coming from wine-users I was suggested to move to this list to solve my problem: I am trying to run a .EXE under wine (updated at 30th of September) on my Ubuntu; the program is a quite expensive Italian dictionary not available on the net. It installs correctly but it crashes just after the start. The message is: - [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/UTETGDU/GDU$ wine gdu.exe err:fixup:apply_relocations No implementation for KERNEL.0, setting to 0xdeadbeef Warning: unprotecting memory to allow real-mode calls. NULL pointer accesses will no longer be caught. fixme:int31:DOSVM_Int31Handler Get Processor Exception Handler Vector (0x01) fixme:int31:DOSVM_Int31Handler Set Processor Exception Handler Vector (0x01) fixme:int31:DOSVM_Int31Handler Set Processor Exception Handler Vector (0x01) fixme:int31:DOSVM_Int31Handler Get Processor Exception Handler Vector (0x01) fixme:int31:DOSVM_Int31Handler Set Processor Exception Handler Vector (0x01) wine: Unhandled exception (thread 000a), starting debugger... WineDbg starting on pid 0x8 fixme:dbghelp:SymLoadModule Should have successfully loaded debug information for image C:\Program Files\UTETGDU\GDU\gdu.exe Modules: Module Address Debug info Name (60 modules) ELF 0x7adb1000-7ae77000 Deferredcomctl32elf \-PE 0x7adc-7ae77000 \ comctl32 ELF 0x7ae77000-7ae96000 Deferrediphlpapielf \-PE 0x7ae8-7ae96000 \ iphlpapi ELF 0x7ae96000-7aedb000 Deferredrpcrt4elf \-PE 0x7aeb-7aedb000 \ rpcrt4 ELF 0x7aedb000-7af6a000 Deferredole32elf \-PE 0x7aef-7af6a000 \ ole32 ELF 0x7af6a000-7afc5000 Deferredshlwapielf \-PE 0x7af8-7afc5000 \ shlwapi ELF 0x7afc5000-7b08f000 Deferredshell32elf \-PE 0x7afe-7b08f000 \ shell32 ELF 0x7b1ab000-7b1c Deferredmidimapelf \-PE 0x7b1b-7b1c \ midimap ELF 0x7b2d7000-7b2fa000 Deferredmsacm32elf \-PE 0x7b2e-7b2fa000 \ msacm32 ELF 0x7b2fa000-7b312000 Deferredmsacm.drvelf \-PE 0x7b30-7b312000 \ msacm.drv ELF 0x7b312000-7b358000 Deferredwineoss.drvelf \-PE 0x7b32-7b358000 \ wineoss.drv ELF 0x7b358000-7b3db000 Deferredwinmmelf \-PE 0x7b36-7b3db000 \ winmm ELF 0x7b3db000-7b43c000 Deferredwinedoself \-PE 0x7b3e-7b43c000 \ winedos ELF 0x7b43c000-7b444000 Deferredlibxrender.so.1 ELF 0x7b444000-7b44d000 Deferredlibxcursor.so.1 ELF 0x7b45d000-7b47a000 Deferredimm32elf \-PE 0x7b46-7b47a000 \ imm32 ELF 0x7b47a000-7b496000 Deferredximcp.so.2 ELF 0x7b496000-7b55b000 Deferredlibx11.so.6 ELF 0x7b55b000-7b568000 Deferredlibxext.so.6 ELF 0x7b568000-7b58 Deferredlibice.so.6 ELF 0x7b58-7b589000 Deferredlibsm.so.6 ELF 0x7b597000-7b599000 Deferredxlcutf8load.so.2 ELF 0x7b599000-7b616000 Deferredwinex11.drvelf \-PE 0x7b5b-7b616000 \ winex11.drv ELF 0x7b616000-7b654000 Deferredadvapi32elf \-PE 0x7b62-7b654000 \ advapi32 ELF 0x7b654000-7b6d5000 Deferredgdi32elf \-PE 0x7b67-7b6d5000 \ gdi32 ELF 0x7b6d5000-7b80 Deferreduser32elf \-PE 0x7b6f-7b80 \ user32 ELF 0x7b80-7b906000 Deferredkernel32elf \-PE 0x7b82-7b906000 \ kernel32 ELF 0x7ba9b000-7bab Deferredwinevdmelf \-PE 0x7baa-7bab \ gdu ELF 0x7bc0-7bc78000 Deferredntdllelf \-PE 0x7bc1-7bc78000 \ ntdll ELF 0x7bd9c000-7bda5000 Deferredlibnss_files.so.2 ELF 0x7bda5000-7bdae000 Deferredlibnss_nis.so.2 ELF 0x7bdae000-7bdc2000 Deferredlibnsl.so.1 ELF 0x7bdc2000-7bdca000 Deferredlibnss_compat.so.2 ELF 0x7bdda000-7bdfb000 Deferredlibm.so.6 ELF 0x7bdfb000-7bef Deferredlibwine_unicode.so.1 ELF 0x7bf0-7bf03000 Deferredwine-loader ELF 0xb7e7d000-b7e8 Deferredlibdl.so.2 ELF 0xb7e81000-b7fae000 Deferredlibc.so.6 ELF 0xb7fae000-b7fbe000 Deferredlibpthread.so.0 ELF 0xb7fbe000-b7fd8000 Deferredlibwine.so.1 ELF 0xb7fea000-b800 Deferredld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0008 (D) C:\Program Files\UTETGDU\GDU\gdu.exe 000a0 == 00090- - - - - - - - - - WineDbg terminated on pid
autoexec.bat and pif's which run batch files
I have not seen this one problem listed and it may be a 1.0 target. Filed bug 3638. Legacy installers modify autoexec.bat to add the install directory to the path and may also use set's. After the installer installs the program will not run as it's bin directory is not in the path. This also could be a reason why many applications only work when run from the directory it is installed in. If windows type is set to 95 or less in winecfg then autoexec should be processed before running the program. I also have programs which uses a pif to run a batch file. The batch in a pif is disabled/stubbed. I plan to look at filling it that feature when I get some time. Paul Romanyszyn
Re: dinput: Fix mouse poll and few other bugs
Am Samstag, 15. Oktober 2005 18:49 schrieb Magnus Olsen: Hi This change allown me run all MS DirectInput sample with out any problem. it also take care of bad writen dinput program that try getting the mouse, Without calling on right api, see my commmect in dinput. I have not tested in wine, But I have tested it in ReactOS and Windows. Did you forget to attach the patch?
Re: preload libGL
Do you need it to fix the mouse pointer lagging problem with fglrx? This patch might be what you need. It works for me with Half-Life and Jedi Academy. I kinda see how this could help, but it would need to be better understood first before being applied (it would need, of course, to not link directly to GL and use function pointers :-) ). Heck, it should make performance almost worse as we add a round-trip to the X server to do this and need to flush the GL rendering pipeline at each buffer swap instead of continuing sending commands to display the new frame while the swap occurs... Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Wine project: Support third party LDDM graphic drivers
Stefan Dösinger wrote: Implementing a wrapper for windows graphics drivers is surely technically interesting, it's an unnecessary effort, which is better invested elsewhere(For example in making the native Linux drivers better). Haven't I heard something analogical before? That'd be... let's see... Wine myth.. #2? There will always be some obscure cards whose manufacturers just don't care about Linux. (-: Are you going to betray everyone that doesn't buy from Nvidia and ATI? :-) Krzysztof
Re: Final call for bug fixes (insert , after DEL)
Detlef Riekenberg wrote: So if you have bugs that you feel must be fixed for 0.9 (and that can be fixed with minimal changes), now is the time to speak up... Has someone a fix for the DEL-Key while NumLock is active - Problem? (inserting a , after deleting the character right from the cursor) nope... my vote on this one too! ( http://bugs.winehq.org/show_bug.cgi?id=2400 )
Re: Final call for bug fixes
On Fri, 21 Oct 2005 15:09:39 +0200, Alexandre Julliard wrote: Folks, I think we are in good shape for the release; the current plan is to release on Tuesday. So if you have bugs that you feel must be fixed for 0.9 (and that can be fixed with minimal changes), now is the time to speak up... Did the unicode controls revert/fix go in? If not then I guess lots of apps will misbehave due to WM_GETTEXT not working properly.
Re: compile wine with icc
Tomas Carnecky wrote: anyone already tried that? I'm getting some errors when compiling wine which I was able to fix, but World of Warcraft won't start... Will icc be supported at some time in the furure? tom last time I checked, icc didn't support stdcall calling convention, which is rather important for compiling wine (on x86) didn't check for its presence lately A+ -- Eric Pouech
Re: compile wine with icc
On 10/16/05, Tomas Carnecky [EMAIL PROTECTED] wrote: I'm getting some errors when compiling wine which I was able to fix, but World of Warcraft won't start... Will icc be supported at some time in the furure? Maybe, especially if people who want it supported pitch in by running the Wine regression tests and reporting any problems.
Re: preload libGL
On Sat, Oct 22, 2005 at 08:39:28PM +0200, Tomas Carnecky wrote: I don't really see any dfference between dlopen(libGL) at run-time and linking x11drv with libGL at compile-time.. Well, suppose you want to do a 'full-blown' Wine distribution. You would then link to libGL at compile time. And then suppose someone uses your package on a machine without GL installed = the guy will not be able to do anything as he won't be able to load the graphics driver (this case actually happened some time back). This is why we try to have less and less 'hard' dependencies in the Wine code and more and more 'soft' ones (which means that you can build Wine on a machine with all dependecies met while having this package still work on a much less feature-full box). Of course, in cases where the dependency is really mandatory (like the GL dependency in the OpenGL32.DLL) we do the hard linking :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Wine project: Support third party LDDM graphic drivers
Haven't I heard something analogical before? That'd be... let's see... Wine myth.. #2? I know of this, and I agree that Wine is a good thing(Otherwise I wouldn't read this list and do any development) But in my opinion, there's a difference in that matter between Applications and Drivers. An application is just something, that sits on top of my Linux installation, while a driver is part of really low-level things. There will always be some obscure cards whose manufacturers just don't care about Linux. That is true, I cannot deny it. But how many Windows only applications are there, and how much Windows-only hardware is out there? I have started a discussion like this on ndiswrapper-devel some time ago, it was about writing a general windows device driver wrapper. No one had a answer wheter such a thing was bad for Linux[1], but the suggestion was dropped because it was too much work for relatively few devices. (The situation why ndiswrapper came into existance was that there was a really high percentatge of unsupported wlan cards, perhaps due to FCC regulations. The FCC states that those cards may only use a certain frequency with a limited power level. Many cards have this control implemented in the driver, so the manufacturers where not allowed to publish an open source driver or the cards specs. And writing a binary only Linux device driver is not comparable to writing a closed-source Linux app. For example, the madwifi driver is basically open source, but it contains a binary only HAL module. The author of the driver wrote this module, but he was told that he wasn't allowed to release the source.) It is different on the application side: Publishing a binary-only app is not magic, you don't need some open-source glue around the binary module and partially recombile the driver against 1001 different kernel versions - So companies to not have the pressure to release their sources(which many do not like). And it's much more likely that you need one specific application, than to need one specific device. It's easier to change an unsupported graphics card than to find a 100% compatible program to Microsoft Access. Windows users often go to the shop and by a replacement device, if the one they have doesn't work out of the box, although they could just download a driver, which is faster and cheaper. Furthermore there's a dependency problem: If I run a Windows application in Linux, there's no problem to terminate that application, the rest of the system will still run. If I have a device driver, I won't be able to use my Linux system without that piece of Win32 code. In such a situation Microsoft might argue that we aren't even able to boot our OS without their code. (-: Are you going to betray everyone that doesn't buy from Nvidia and ATI? :-) Just out of curiosity: Can you name any graphics card which doesn't have a Linux driver? I haven't seen such a device yet. Relying on Windows drivers would, on the oder hand, betray anyone who is not using x86 hardware. Stefan [1]: It turned out that there are some Wlan device manufacturers which deny to write Linux drivers and tell Linux users to use the Win32 driver and Ndiswrapper. It was said that there was even one company which stopped their Linux driver development due to ndiswrapper. On the other hand, the Linux wlan driver situation is not as bad as it was 2 years ago: Drivers were released for the Intel pro/wireless cards(Centrino!), the realtek wlan chip and others. The only chip that needs ndiswrapper that I know is the broadcom chip, and there's a reverse engineering in progress. One curiosity about the broadcom chip: There is a Linux driver, it's used in a wireless lan access point which uses Linux. I don't know why Broadcom didn't release their driver.
Re: preload libGL
Hello, I kinda see how this could help, but it would need to be better understood first before being applied (it would need, of course, to not link directly to GL and use function pointers :-) ). Heck, it should make performance almost worse as we add a round-trip to the X server to do this and need to flush the GL rendering pipeline at each buffer swap instead of continuing sending commands to display the new frame while the swap occurs... I am not a GL expert, but AFAIK the OpenGL spec requires the app to flush the rendering pipeline before swapping the buffers. Many games don't do so(ut, Q3 friends, Half-Life, ...) Most drivers are prepared for this, so it doesn't make any problems. It's only the fglrx driver that can't cope with it, and it makes the mouse pointer lagging for up to one secound, which makes FPS games unplayable. The best solution would be to fix the games, maybe ATI could fix their driver, but so far there are only hacks like my patch or a preloaded library with a custom glXSwapBuffers. Stefan
Re: preload libGL
On Sat, Oct 22, 2005 at 11:06:14PM +0200, Tomas Carnecky wrote: I personally would vore for the first option, make opengl a wine requirement, we'll soon have opengl integrated into the xserver (Xgl etc.) so sooner or later everyone will need to have an opengl implementation installed. Well, trust me on that one, but some times ago, Wine did link directly to OpenGL. But seeing the number of broken packages (i.e. did not advertise the GL dependency) and the time spent on bug reports / support requests, it was decided to move to a run-time link scheme. And I think there are more people without GL installed (and without even a clue to what GL is) than one wanting to play pre-link tricks to override GL. opengl should be installed per default on all desktop boxes (at least through mesa in pure-GPL duistributions that don't want to have any proprietary binaries).. Maybe when it will be really mandatory we can switch back to 'hard' linking. But for now, I think GL is not yet pre-installed on all distributions and we will still have to wait a while to get to the Xgl and all other eye-candy infested stuff they are writing :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Solaris Updates
I have posted my local patches to wine-patches. Note that for 0.9 I have posted most of the patches that are likely to be essential to build a working Wine package (other than those previously rejected) regardless of the shape the code is in. Some of it is very ugly and lacks integration for other OSen, I have noted these. Since this code is maintained as a delta from CVS wine specific to Solaris and only used for binary packages, it's not necessary to start out with the niceties all there (This particularly happens when I get deep into week long debugging sessions). Patches not sent are listed hereunder long with the reasons... Possibly essential (Show stoppers) ptrace stub patch - Disable debugger by returning error for all ptrace calls, add ptrace stubs (framework) to allow work on ptrace emulation layer for wine. -Previously rejected linking patch - since libwinecrt0.a was added wine has been broken due to the linker wanting to import main() in dlls, this results in unresolved symbols. I have temporarily worked around this and can build wine with a change to winegcc that links another archive (I call winedllcrt0.a) which omits the main() definitions in the case where -shared is passed to winegcc. Alexandre has asked that I keep looking for a way to make the Solaris linker successfully link an archive containing main() to dlls without the need to have two runtime startoff libraries. Patch won't be submitted until a final solution is found. Recommended functionality patches cpuid patch - CPUID detection using x86 cpuid instruction - previously rejected wineconsole/curses.c - Patch non-essential and FAR too hacky at this point - just removes all mouse code. Other Patches tools - automation patches to allow unattended build No interest to Wine project Debugger - work in progress, not working A complete set of patches (even the gross ones) are maintained at http://www.blastwave.org/wine
Re: compile wine with icc
That's expected. To support icc, one would have to adjust the commandline options a bit depending on the compiler being used. In particular, one would want to suppress many compiler warnings like the ones you mentioned. icc provides a nice way of suppressing any desired set of warnings.
Re: Shell32 File Property dialog
Johannes Anderwald wrote: I have a patch which adds file property dialogs to shell32 Looks like you've written the patch for ReactOS... it doesn't apply to the current Wine tree. I think you need to do a little bit more work to get it ready for submission: * use TRACE instead of DPRINT * don't use %S in debug statements (with TRACE) it's not portable, use %s and debugstr_w(str) instead * in SH_FileVersionDlgProc you miss a break at the end of WM_COMMAND * the formatting is all over the place. 4 space indent, no tabs is prefered * make sure to use the A or W functions and types explicitly. eg. you use PROPSHEETPAGE where you should use PROPSHEETPAGEW. * this comments looks dodgy: SH_FileTimerProc is invoked every 100ms to check if the property sheet should be closed required because the property sheet pages are MODELESS Your Window proc will get a WM_CLOSE when you need to close, or WM_DESTROY when it is destroyed. Freeing memory and other things that need to be done when the window is closed should happen in the Window procedure, and there should be no need for a timer. Please take the time to build you patch with and generate it against the CVS version of WineHQ. thanks for the patch, Mike
