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
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.
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: 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/
Re: Final call for bug fixes
Saturday, October 22, 2005, 12:53:36 PM, Mike Hearn wrote: > 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. Not exactly a revert but disable patch when in, if there is no active theme selected. Vitaliy
Re: preload libGL
> I am not a GL expert, but AFAIK the OpenGL spec requires the app to flush the > rendering pipeline before swapping the buffers. I would find this extremely strange. For example, the 'glXSwapBuffers' man page says this: (...) The update typically takes place during the vertical retrace of the monitor, rather than immediately after glXSwapBuffers is called. glXSwapBuffers performs an implicit glFlush before it returns. Subsequent OpenGL commands may be issued immedi- ately after calling glXSwapBuffers, but are not executed until the buffer exchange is completed. The only mention I have of 'glFinish' being useful is when multiple GLX contexts share the same double buffered window (a bit later in this man page). So I would definitely think that this is a bug in the fglrx drivers and Wine is not the place to fix it... Lionel PS: but thanks to have made me re-read the man page, it gives ideas on how to try to solve the multi-threaded D3D games problem :-) -- Lionel Ulmer - http://www.bbrox.org/
Re: Final call for bug fixes
Vincent Béron wrote: Le ven 21/10/2005 à 10:05, Dimi Paun a écrit : From: "Alexandre Julliard" <[EMAIL PROTECTED]> I think we are in good shape for the release; the current plan is to release on Tuesday. Speaking of which, what's the status for our FC builds? We really need binary builds for Fedora for this release. It would be a pitty to fail to provide binary .rpms for this one, while we have constantly provided them for all the alpha releases for more then one (two?) years now. 20050930 is on sf for all but CentOS 4 (haven't had time to update my CentOS 4 installation yet). The download page on winehq hasn't been updated yet because it's a mess when all RH-distros are not ready at the same time. I won't be home this week-end, so it'll go to Monday night at the earliest. Vincent Ubuntu/Debian seems to be old. At least apt-get isn't upgrading me: [EMAIL PROTECTED]:~$ wine --version Wine 20050725
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: 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
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: 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: 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: 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: 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: 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: 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: preload libGL
Am Mittwoch, 12. Oktober 2005 11:55 schrieb Tomas Carnecky:
> 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.
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 have hacked this change into my x11drv long ago, but I have never submitted
a patch? Might a patch like this go into CVS?
Stefan
Index: dlls/x11drv/Makefile.in
===
RCS file: /home/wine/wine/dlls/x11drv/Makefile.in,v
retrieving revision 1.43
diff -u -r1.43 Makefile.in
--- dlls/x11drv/Makefile.in 6 May 2005 19:38:50 - 1.43
+++ dlls/x11drv/Makefile.in 22 Oct 2005 17:49:23 -
@@ -5,7 +5,7 @@
MODULE= winex11.drv
IMPORTS = user32 gdi32 advapi32 kernel32 ntdll
EXTRAINCL = @X_CFLAGS@
-EXTRALIBS = $(LIBUNICODE) @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@
+EXTRALIBS = $(LIBUNICODE) @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@ @OPENGL_LIBS@
C_SRCS = \
bitblt.c \
Index: dlls/x11drv/opengl.c
===
RCS file: /home/wine/wine/dlls/x11drv/opengl.c,v
retrieving revision 1.16
diff -u -r1.16 opengl.c
--- dlls/x11drv/opengl.c 28 Sep 2005 18:11:17 - 1.16
+++ dlls/x11drv/opengl.c 22 Oct 2005 17:49:24 -
@@ -462,6 +462,7 @@
TRACE("(%p)\n", physDev);
wine_tsx11_lock();
+ glFinish();
pglXSwapBuffers(gdi_display, physDev->drawable);
wine_tsx11_unlock();
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: Wine project: Support third party LDDM graphic drivers
Hello, > 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). I haven't looked at the tecnical side of this, but while support for LDDM drivers might bring the advantages above, it also has drawbacks: * It might be a part of Wine functionality that is limited to Linux. * It will always be limited to X86 and X86_64 architectures only. The Linux graphics driver situation is not bad, in my opinion. The nvidia driver is good, some say it's better than the windows driver. The ati fglrx driver's quality isn't that shiny, and I have a lot of problems with it, but it's getting better and better. The intel graphics chips have Open Source drivers, as do the ATI radeon chips, and the nvidia chips(2D only). The bigest problems are Linux specific graphic functionalities, like Xinerma, and Windows drivers will never ever help with this - Look at the ndiswrapper project, it will never be able to provide a master mode, because ndis doesn't support it. One thing that could improve is the 3D acceleration speed, but I doubt it will be much better. Take the ATI cards: The Linux driver is slow compared to the Windows driver. But when I played some games in Windows on my notebook(Radeon 9000 Mobility) the last time(1 Year ago, approximately), this was true for DirectX games only. A friend of mine, who has the same hardware, still has problems with OpenGL games like Half-Life 1 and Jedi Academy in WinXP, games that perform really fine with fglrx in Wine. 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). And it is definitly a thing that ReactOS should have. Stefan
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: preload libGL
On Wed, Oct 12, 2005 at 11:55:10AM +0200, Tomas Carnecky wrote: > 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. Out of curiosity, why do you need this ? > What about linking x11drv directly with libGL? If we do this, we will get a hard dependency between Wine and OpenGL which will lead to a lot of packaging nightmares. Lionel -- Lionel Ulmer - http://www.bbrox.org/
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 Deferredcomctl32 \-PE 0x7adc-7ae77000 \ comctl32 ELF 0x7ae77000-7ae96000 Deferrediphlpapi \-PE 0x7ae8-7ae96000 \ iphlpapi ELF 0x7ae96000-7aedb000 Deferredrpcrt4 \-PE 0x7aeb-7aedb000 \ rpcrt4 ELF 0x7aedb000-7af6a000 Deferredole32 \-PE 0x7aef-7af6a000 \ ole32 ELF 0x7af6a000-7afc5000 Deferredshlwapi \-PE 0x7af8-7afc5000 \ shlwapi ELF 0x7afc5000-7b08f000 Deferredshell32 \-PE 0x7afe-7b08f000 \ shell32 ELF 0x7b1ab000-7b1c Deferredmidimap \-PE 0x7b1b-7b1c \ midimap ELF 0x7b2d7000-7b2fa000 Deferredmsacm32 \-PE 0x7b2e-7b2fa000 \ msacm32 ELF 0x7b2fa000-7b312000 Deferredmsacm.drv \-PE 0x7b30-7b312000 \ msacm.drv ELF 0x7b312000-7b358000 Deferredwineoss.drv \-PE 0x7b32-7b358000 \ wineoss.drv ELF 0x7b358000-7b3db000 Deferredwinmm \-PE 0x7b36-7b3db000 \ winmm ELF 0x7b3db000-7b43c000 Deferredwinedos \-PE 0x7b3e-7b43c000 \ winedos ELF 0x7b43c000-7b444000 Deferredlibxrender.so.1 ELF 0x7b444000-7b44d000 Deferredlibxcursor.so.1 ELF 0x7b45d000-7b47a000 Deferredimm32 \-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.drv \-PE 0x7b5b-7b616000 \ winex11.drv ELF 0x7b616000-7b654000 Deferredadvapi32 \-PE 0x7b62-7b654000 \ advapi32 ELF 0x7b654000-7b6d5000 Deferredgdi32 \-PE 0x7b67-7b6d5000 \ gdi32 ELF 0x7b6d5000-7b80 Deferreduser32 \-PE 0x7b6f-7b80 \ user32 ELF 0x7b80-7b906000 Deferredkernel32 \-PE 0x7b82-7b906000 \ kernel32 ELF 0x7ba9b000-7bab Deferredwinevdm \-PE 0x7baa-7bab \ gdu ELF 0x7bc0-7bc78000 Deferredntdll \-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 Deferred 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 0x8 - - - - - - - - I have followed Daniel's suggestion to run the comm
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* M;B Q+CDX"[EMAIL PROTECTED]@[EMAIL PROTECTED] @+7(Q+CDX([EMAIL PROTECTED]
> M;F=E3&]G"3,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]&QL M;" \;2YG;V5M;65L0&-O;7!U;&%B+F1E/@HK"4UI M:&5C:V)O>&5S('=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;&EA[EMAIL PROTECTED]&QL M;BYC"CT]/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;BYC"BTM+2!D;&QS
> M+W5S97(O8G5T=&]N+F,),3(@4V5P(#(P,#4@,3(Z,C Z,S@@+3 P,# ),2XY
> M"BLK*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$ @ 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@(" @"YT;W @/2!R=&5X="YT;W ["BT@
> M(" @"YB;W1T;VT@/2!R=&5X="YB;W1T;VT["BL@(" @[EMAIL PROTECTED]>2!A
> M9&IU"!W:&5N(')T97AT(&ES('9A;&ED("HO"BL@(" @:[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!$ M*&%C=&EO;B ]/2!/1$%?1%)!5T5.5$E212!\?"!A8W1I;VX@/[EMAIL PROTECTED]
> M3$5#5"D*(" @("!["D! ("TY-#8L-R K.34Q+#<@0$ @ M0T)?4&%I;G0H($A73D0@:'=N9"[EMAIL PROTECTED](&A$0PH@"0ER8F]X+G1O<" ](')B
> M;[EMAIL PROTECTED]&]M("[EMAIL PROTECTED]";WA(96EG:'0["B )(" @('[EMAIL
> PROTECTED]"B )
> M"7)B;[EMAIL PROTECTED]&]M("L]("UD96QT82\R("L@,3L*+0D)"YT;W @/2!R
> M8F]X+F)O='1O;2 M/2!C:&5C:T)O>$AE:6=H=#L**PD)"YT;W @/2!R
> M8F]X+F)O='1O;2 M(&-H96-K0F]X2&5I9VAT.PH@"2 @("!]"B )?2!E;'-E
> H('[EMAIL PROTECTED]@1&5F875L=" J+PH@"2 @("!I9B H9&5L=&$@/B P*2!["@``
> `
> end
pgpXiRgcZIBMy.pgp
Description: PGP signature
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 */
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: 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
Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back
Mike Hearn 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: [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
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
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
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=1307&versionId= (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
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!
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=2954&d=21-10
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 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...
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]
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 L"C:\\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: 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
