Vitaliy Margolen <wine-patch(a)kievinfo.com> writes:
> ChangeLog:
> wine.inf: Add user "Shell Folders\Font" entry.
This should go with the other shell folder registration stuff in
shell32.
--
Alexandre Julliard
julliard(a)winehq.org
Robert Reif <reif(a)earthlink.net> writes:
> Fix CreateThread/waveOutOpen race by forcing parent thread to sleep
> which allows background thread to run and block before waveOutOpen is
> called.
If the background thread has to run for things to work, you need to
add a real synchronisation mechanism. A Sleep is not fixing anything,
it's just making the race condition less likely.
--
Alexandre Julliard
julliard(a)winehq.org
Nik wrote:
> [I build my Windows apps on Win2k. How can I do it on Linux?
> winegcc doesn't seem the right way.]
Depends. If your apps use C++, and you need to be able to
access non-COM C++ DLLs compiled by other folks, I bet
the best way to go is just run the same development tools
you used on Win2k under Wine.
You might be able to just run the Visual C++ setup under Wine
and get the IDE running. Or if the commandline is enough for you,
see http://kegel.com/wine/cl-howto.html for how I used to set that up.
Or, if you can get away with using Mingw instead of Microsoft's compiler,
see http://www.winehq.com/site/docs/winedev-guide/cross-compiling-tests
for info about how to set up a mingw cross-compiler.
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Opening up the debate again on the World of Warcraft ( WoW ) memory patch.
Some facts about WoW that may explain why the AppDB page is pretty
active and the wow patch for wine 0.9.12 was downloaded over 1000 times
from the Appdb page during a 4 week period.... Wow has approximately 6
million players that each pay about $90/year for the priviledge of
connecting to a WoW server (Realm). Assuming this figure is broadly
correct, Blizzard therefore receives $500,000,000/year just from this
game in subscriptions. ( This doesn't include the cost of buying the
game in the first place ). Perhaps Blizzard would like to employee a
programmer fulltime just to work on the wine project to help make Wow
run 100% ?.
Anyway with the popularity of this game in mind, you can see why there
is a lot of interest in making this patch a thing of the past, so the
thousands of gamers who play this game on wine don't have to keep
applying a special patch. I would be grateful for any suggestions as to
how we could incorporate this patch so that it is no longer necessary. I
know we can't simply include the patch, but there must be some way
around this problem ?
Below is an email regarding this partiicular problem, I would be
grateful for any comments that I can pass back to Jan Riewe. Thanks
Regards
Nick Law
Appdb Maintainer - World of Warcraft 1.10.x
Any feedback is much appreciated.
Comment for 'World of Warcraft 1.10.x' added by jan riewe
-------------------------------------------------------
To reply to this email please use the link provided below.
DO NOT reply via your email client as it will not reach the person who wrote the comment
http://appdb.winehq.org/appview.php?versionId=4031&mode=nested#Comment-12086
Subject: RE: is this a workaround or a real patch?
is it posible to make a workaround with the user.reg? in the transgaming forum i`ve found something like :
[Software\\Wine\\AppDefaults\\WoW.exe\\Memory] 1148134976
"MemoryLayoutOverride"="0x10000000"
does it make sense on wine? (i am not so familiar to the wine syntax *shame on me*) is this perhaps the key to get rid of the patches and make the binary build of wine working with WoW also fine?
if this is a posibility perhaps you can post a full "user.reg" fix for those of us, who love the update feature.
and i just want to thank you ... your service this really great! wow is one of the biggest steps at the moment for gaming society to move more and more to an opensource system.
----
--- wine/libs/wine/mmap.c.orig 2006-05-11 17:02:13.000000000 +0100
+++ wine/libs/wine/mmap.c 2006-05-19 22:08:03.000000000 +0100
@@ -183,7 +183,26 @@
#endif /* (__svr4__ || __NetBSD__) && !MAP_TRYFIXED */
+static void *get_anon_mmap_null_address(size_t size)
+{
+ static int got_override = 0;
+ static void *low_alloc_ptr = NULL;
+ void * current_low_alloc_ptr;
+
+ if (!got_override)
+ {
+ low_alloc_ptr = (void*)0x10000000;
+ got_override = 1;
+ }
+
+ current_low_alloc_ptr = low_alloc_ptr;
+
+ if (low_alloc_ptr)
+ low_alloc_ptr += size;
+ return current_low_alloc_ptr;
+ }
+
/***********************************************************************
* wine_anon_mmap
*
@@ -213,6 +232,8 @@
return start;
#endif
}
+ if ((start == NULL) && !(flags & MAP_FIXED))
+ start = get_anon_mmap_null_address(size);
return mmap( start, size, prot, flags, get_fdzero(), 0 );
}
--- wine/loader/preloader.c.orig 2006-05-11 17:02:13.000000000 +0100
+++ wine/loader/preloader.c 2006-05-19 22:14:22.000000000 +0100
@@ -109,8 +109,8 @@
static struct wine_preload_info preload_info[] =
{
{ (void *)0x00000000, 0x00110000 }, /* DOS area */
- { (void *)0x7ffe0000, 0x01020000 }, /* shared user data + shared
heap */
- { (void *)0x00110000, 0x1fef0000 }, /* PE exe range (may be set
with WINEPRELOADRESERVE), defaults to 512mb */
+ { (void *)0x80000000, 0x01000000 }, /* shared user data + shared
heap */
+ { (void *)0x10000000, 0x00f00000 }, /* PE exe range (may be set
with WINEPRELOADRESERVE), defaults to 512mb */
{ 0, 0 } /* end of list */
};
--
Regards
Nick Law
Mobile: 07736 022165
Email: nick.law(a)mic-nucmed.co.uk
Medical Imaging Consultancy Ltd (M.I.C)
Sales and Service of ADAC and IS2 Products
http://www.mic-nucmed.co.uk
Mike McCormack <mike(a)codeweavers.com> writes:
> @@ -153,7 +153,7 @@ static LRESULT WINAPI WCUSER_FontPreview
> SetWindowLong(hWnd, 0, 0);
> break;
> case WM_GETFONT:
> - return GetWindowLong(hWnd, 0);
> + return GetWindowLongPtr(hWnd, 0);
> case WM_SETFONT:
> SetWindowLong(hWnd, 0, wParam);
> if (LOWORD(lParam))
You should fix all the Get/SetWindowLong calls that set the same
value, changing only half will make things worse. You also have to
reserve the proper size in the window class.
--
Alexandre Julliard
julliard(a)winehq.org
I'm working on the conversion from DirectX pixel and vertex shaders to
GLSL function and have made a good bit of progress this weekend. At
the moment, I'm able to run just about every simple vertex shader
(version <= 1.4, and a few 2.0's) that I can find which already works
on ARB_vertex_program (the current way that Wine handles this). I'm
having a bit more trouble with pixel shaders, but I haven't really dug
into it yet. Some of the really simple ones work, but I believe I'm
missing a step in the texture binding code somewhere.
I've posted a patch to enable this shader generation here:
http://cmhousing.net/wine/glsl_hack4.diff
If you want to try this and help debug things, you'll have to apply
the patch (it's against the current git tree as of 2:00 AM EST, May
30th). Plus, you'll need a video card and driver capable of using
GLSL (type 'glxinfo' and look for "GL_ARB_shading_language_100") .
You'll also have to set a new registry key in your Wine installation
(it is case sensitve):
HKEY_CURRENT_USER\Software\Wine\Direct3D\UseGLSL = "enabled"
Here are a few comparison screenshots (note, yes, they should be identical ;-):
http://www.cmhousing.net/wine/aniso_arb.png (vanilla wine, or with
UseGLSL != "enabled")
http://www.cmhousing.net/wine/aniso_glsl.png (using GLSL)
http://www.cmhousing.net/wine/grass_arb.pnghttp://www.cmhousing.net/wine/grass_glsl.pnghttp://www.cmhousing.net/wine/dolphin2_glsl.png (DX8 SDK dolphin sample)
http://www.cmhousing.net/wine/civ4_glsl.png (not *quite* there yet ;-)
In theory, once this all works, we'll be able to support shader model
2.0+, which a lot of newer games either require or strongly suggest
(aka prettier graphics). Now, there are plenty of other bugs to be
worked out in wined3d, so this isn't the holy grail of patches or
anything, but it will take us that much closer to supporting new
games. Please lend a hand if you're able to. Thanks!
(by the way, many thanks to the entire #winehackers crew for all the
help along the way so far, it's been fun)
Hi!
I would like to ask for a help with wine compilation on an x86_64 system.
Today I successfully did the compilation, but the result is totally unusable.
I've supplied -m32 switch to both CFLAGS and LDFLAGS (I have to specify my
own C/LDFLAGS because of custom -I/-L options to find various packages). gcc
as well as winegcc correctly generated 32bit output.
There was just one error during compilation - it attempted to compile
dlls/ntdll/signal_i386.c, which suffered from __NR_sigaction being undefined.
Because my kernel headers are set up for a 64bit system, there is not such a
define. __NR_rt_sigaction is defined instead. I'm not sure whether it's ok
that wine tried to compile this file (it compiled signal_x86_64.c too, with
no problems). I also don't know how to hack the kernel includes to define it
correctly (I have just vanilla, unmodified set of native kernel headers for
2.6.17-rc5 set up). So I hacked it by copying the appropriate #define
from asm-i386/unistd.h kernel header directly to signal_i386.c.
wine then compiled and installed without a glitch. However, any attempt to
run it ends up with immediate return without any diagnosis. It even doesn't
output its usage help.
I've already compiled a lot of "normal" programs for 32bit systems on my
x86_64 system. However, wine resists.
What am I doing wrong ? What's the correct way ?
With regards, Pavel Trolle
Hi Alexandre,
I'm curious as to what the reason behind this change was. I was under the
impression an invalid request must always mean a corrupted/destabilised
client. Please give me insight! :)
thanks -mike
I am running wine (including winelib development packages) un Ubuntu
6.x beta, and I'd like, if possible, to migrate my Win32 development
from Win2k to Ubuntu (where most of my development is done).
Further to winelib information found in
http://www.winehq.org/site/winelib and makefile examples from
http://www.computersciencelab.com/Petzold.htm, I came to the
conclusion that it should be possible to build, under Linux, a single
.exe file that would run under both wine on Linux and on win2k. One of
the simplest examples in ...Petzold.htm above (clover.c) can be
compiled and linked as:
winegcc -c -mno-cygwin clover.c
winegcc -o clover.exe clover.o -mno-cygwin -mwindows -lcomctl32
-lcomdlg32 -lwinmm -ladvapi32 -lwinspool
Both steps run with no errors, but the result is clover.exe.so and a
shell script clover. Either will run under Ubuntu/wine, but .so is of
course not a win32 executable.
Is my assumption that it is possible to build a win32 executable using
winegcc on Linux correct? If yes, I must be missing something rather
obvious: any pointer will be appreciated.
TIA, Nik N.