Re: WoW, er Wine on Windows--Re: Still more fun?
Mike McCormack wrote: Augustus Saunders wrote: As for what we hope to accomplish, well, it might seem like massive overkill to try using WINE, but it's the only plausible way I've come up with. Basically, we want to substitute all the graphics/windowing/GDI etc so that we can record all the painting/rendering into some kind of WMF type thingy. The idea is to get screen captures as metafiles that are perfectly screen-accurate. Sounds like a modified screen driver would do a better job at what you want. I don't know whether a modified graphic driver will capture EVERYTHING he's trying to catch, but using Wine does not sound like the right solution either. I'd use the same injection technique Wine uses to inject my own DLLs that just forward everything on to native, and then use that to record whatever is interesting to me. It sounds like what Wine is doing will only hurt what Augustus is trying to do, not help. There are also more Traditional ways to inject your code into a process's import table. Mike Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Some fixes for filtergraph.c
Hi Maarten,
Maarten Lankhorst wrote:
This doesn't fix everything, just theroutines i called.. some other
similar functions aren't fixed because filtergraph.c is really THAT
leaky..b mostly with reference counts..
Yes, Indeed. :-)
Here are some comments :
--- wine-20050310/dlls/quartz/filtergraph.c 2005-03-02 11:12:12.0
+0100
+++ wine/dlls/quartz/filtergraph.c 2005-04-24 00:50:30.0 +0200
@@ -556,8 +556,7 @@
IPin_QueryDirection(ppin, pindir);
if (pindir == PINDIR_OUTPUT)
i++;
-else
-IPin_Release(ppin);
+IPin_Release(ppin);
}
*pppins = CoTaskMemAlloc(sizeof(IPin*)*i);
/* Retrieve output pins */
@@ -650,6 +649,7 @@
IPin** ppins;
IPin* ppinfilter;
IBaseFilter* pfilter = NULL;
+BOOL HaveEnumPin = FALSE;
Why don't you just set ppinfilter to NULL
and do if (ppinfilter) IPin_Release(ppinfilter); at the end ?
hr = GetFilterInfo(pMoniker, clsid, var);
IMoniker_Release(pMoniker);
@@ -677,6 +677,7 @@
ERR(Enumpins (%lx)\n, hr);
goto error;
}
+
hr = IEnumPins_Next(penumpins, 1, ppinfilter, pin);
if (FAILED(hr)) {
ERR(Next (%lx)\n, hr);
@@ -687,6 +688,7 @@
goto error;
}
IEnumPins_Release(penumpins);
+HaveEnumPin = TRUE;
See above.
hr = IPin_Connect(ppinOut, ppinfilter, NULL);
if (FAILED(hr)) {
@@ -703,17 +705,21 @@
TRACE(pins to consider: %ld\n, nb);
for(i = 0; i nb; i++) {
TRACE(Processing pin %d\n, i);
-hr = IGraphBuilder_Connect(iface, ppins[0], ppinIn);
+hr = IGraphBuilder_Connect(iface, ppins[i], ppinIn);
if (FAILED(hr)) {
-TRACE(Cannot render pin %p (%lx)\n, ppinfilter, hr);
-return hr;
+ TRACE(Cannot render pin %p (%lx)\n, ppinfilter, hr);
}
+IPin_Release(ppins[i]);
+if (SUCCEEDED(hr)) break;
This is not correct, you must connect all pins, not just the first that
succeeds.
}
CoTaskMemFree(ppins);
+IBaseFilter_Release(pfilter);
+IPin_Release(ppinfilter);
+break;
}
-break;
error:
+if (HaveEnumPin) IPin_Release(ppinfilter);
See above.
if (pfilter) {
IGraphBuilder_RemoveFilter(iface, pfilter);
IBaseFilter_Release(pfilter);
@@ -1175,13 +1181,16 @@
ULONG nb;
ULONG i;
PIN_INFO PinInfo;
+BOOL HavePinInfo = FALSE;
TRACE(%p %p %lld\n, pGraph, pOutputPin, tStart);
hr = IPin_ConnectedTo(pOutputPin, pInputPin);
-if (SUCCEEDED(hr))
+if (SUCCEEDED(hr)) {
+HavePinInfo = TRUE;
hr = IPin_QueryPinInfo(pInputPin, PinInfo);
+}
Personally, I would set PinIno.pFilter to NULL on failure and do if
(PinIno.pFilter) release... at the end.
But it's just a matter of taste.
if (SUCCEEDED(hr))
hr = GetInternalConnections(PinInfo.pFilter, pInputPin, ppPins, nb);
@@ -1202,6 +1211,7 @@
* FIXME: We should prevent exploring from a pin more than
once. This can happens when
* several input pins are connected to the same output (a MUX
for instance). */
ExploreGraph(pGraph, ppPins[i], tStart);
+IPin_Release(ppPins[i]);
}
CoTaskMemFree(ppPins);
@@ -1210,6 +1220,7 @@
IBaseFilter_Run(PinInfo.pFilter, tStart);
}
+if (HavePinInfo) IBaseFilter_Release(PinInfo.pFilter);
return hr;
}
@@ -1255,9 +1266,11 @@
IPin_QueryDirection(pPin, dir);
if (dir == PINDIR_INPUT)
{
+IPin_Release(pPin);
source = FALSE;
break;
}
+IPin_Release(pPin);
That would be simplier to do a single call to IPinRelease after
IPin_QueryDirection.
}
if (source == TRUE)
{
@@ -1267,6 +1280,7 @@
{
/* Explore the graph downstream from this pin */
ExploreGraph(This, pPin, 0);
+IPin_Release(pPin);
}
IBaseFilter_Run(pfilter, 0);
}
Nice patch, BTW! :-)
Bye,
Christian
Re: Copy Protection
Dustin Navea wrote: Guys, bug 2895 got me thinkin.. If we only support a handful of games that use copy protection, shouldnt we file a bug in Bugzilla and append that to 1434 (Get games working perfectly)? That way we can attach any copy protection related bugs to this metabug? Yes I think it's a good idea. Ivan.
Odd problem with process handles
I am having a problem with the attached segfault in ie6
I have attached a gdb backtrace and the last part of a relay dump.
hModule is 0xe and gets dereferenced to find e_magic presumably from
the psp.
Obviously dereferencing 0xfffe is not good which raises an exception
The exception is caught and appears to be ignored the first time it occurs but
this seems unusual to me
Can anyone shed light on this, is this normal or do I have a problem. What's
going on here ?
More info follows
Bob
Starting program: /opt/cfw/wine/bin/wine iexplore
Program received signal SIGSEGV, Segmentation fault.
0xd1cbfb5f in RtlImageNtHeader (hModule=0xfffe) at loader.c:1907
1907if (dos-e_magic == IMAGE_DOS_SIGNATURE)
(gdb) print dos
$1 = (IMAGE_DOS_HEADER *) 0xfffe
*** Aparrently in this code
1895/***
1896 * RtlImageNtHeader (NTDLL.@)
1897 */
1898PIMAGE_NT_HEADERS WINAPI RtlImageNtHeader(HMODULE hModule)
1899{
1900IMAGE_NT_HEADERS *ret;
1901
1902__TRY
1903{
1904IMAGE_DOS_HEADER *dos = (IMAGE_DOS_HEADER *)hModule;
(gdb)
1905
1906ret = NULL;
1907if (dos-e_magic == IMAGE_DOS_SIGNATURE)
1908{
1909ret = (IMAGE_NT_HEADERS *)((char *)dos + dos-e_lfanew);
1910if (ret-Signature != IMAGE_NT_SIGNATURE) ret = NULL;
1911}
1912}
1913__EXCEPT(page_fault)
1914{
(gdb)
1915return NULL;
1916}
1917__ENDTRY
1918return ret;
1919}
Relay output
00b:Ret kernel32.LoadLibraryA() retval= ret=70c2429c
000b:Call kernel32.GetLastError() ret=70c242a9
000b:Ret kernel32.GetLastError() retval=007e ret=70c242a9
000b:Call kernel32.InterlockedExchange(70c2bd84,) ret=70c242f0
000b:Ret kernel32.InterlockedExchange() retval= ret=70c242f0
000b:Call kernel32.GetProcAddress(,70c24832 ApphelpCheckShellObject)
ret=70c24399
000b:Call ntdll.RtlInitAnsiString(7fd8dc18,70c24832 ApphelpCheckShellObject)
ret=7fe1e655
000b:Ret ntdll.RtlInitAnsiString() retval=7fd80018 ret=7fe1e655
000b:Call ntdll.LdrGetProcedureAddress(,7fd8dc18,,7fd8dc20)
ret=7fe1e667
GDB Backtrace
(gdb) bt
#0 0xd1cbfb5f in RtlImageNtHeader (hModule=0xfffe) at loader.c:1907
#1 0xd1cc0018 in RtlImageDirectoryEntryToData (module=0xfffe, image=0,
dir=0, size=0x7fd8db3c) at loader.c:2025
#2 0xd1cbdcd1 in LdrGetProcedureAddress (module=0x, name=0x7fd8dc18,
ord=0, address=0x7fd8dc20) at loader.c:1154
#3 0xd1ccabcf in call_stdcall_function (func=0xd1cbdc9b
LdrGetProcedureAddress, nb_args=4, args=0x7fd8dc08) at relay.c:521
#4 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=2145511015) at relay.c:603
#5 0xd1d00025 in __wine_spec_exp_ordinals () from
/opt/cfw/wine/lib/wine/ntdll.dll.so
#6 0xd1ccab7d in call_stdcall_function (func=0x7fe1e62b GetProcAddress,
nb_args=2, args=0x7fd8dce4) at relay.c:519
#7 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=1891779481) at relay.c:603
#8 0x7fec08dd in __wine_spec_forwards () from
/opt/cfw/wine/lib/wine/kernel32.dll.so
#9 0x70c23bd1 in ?? ()
#10 0x71191420 in ?? ()
#11 0x711819aa in ?? ()
#12 0x7118a3c9 in ?? ()
#13 0x71165a1c in ?? ()
#14 0x7fbab1af in WINPROC_wrapper () from /opt/cfw/wine/lib/wine/user32.dll.so
#15 0x7fbab61d in WINPROC_CallWndProc (proc=0x71165af5, hwnd=0x20022, msg=129,
wParam=0, lParam=2144920548)
at ../../windows/winproc.c:418
#16 0x7fbb21a6 in CallWindowProcA (func=0x71165af5, hwnd=0x20022, msg=129,
wParam=0, lParam=2144920548)
at ../../windows/winproc.c:3202
#17 0x7fbea1f4 in call_window_proc (hwnd=0x20022, msg=129, wparam=0,
lparam=2144920548, unicode=0, same_thread=1)
at message.c:1521
#18 0x7fbec0cb in SendMessageTimeoutA (hwnd=0x20022, msg=129, wparam=0,
lparam=2144920548, flags=0, timeout=4294967295,
res_ptr=0x7fd8df78) at message.c:2376
#19 0x7fbec299 in SendMessageA (hwnd=0x20022, msg=129, wparam=0,
lparam=2144920548) at message.c:2420
#20 0xd1ccabcf in call_stdcall_function (func=0x7fbec266 SendMessageA,
nb_args=4, args=0x7fd8e040) at relay.c:521
#21 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=2137925787) at relay.c:603
#22 0x7fc3e3a1 in __wine_spec_exp_ordinals () from
/opt/cfw/wine/lib/wine/user32.dll.so
#23 0xd1cca480 in call_cdecl_function (func=0x7f6e23b6 X11DRV_CreateWindow,
nb_args=3, args=0x7fd8e1c0) at relay.c:462
#24 0xd1ccb2c2 in RELAY_CallFrom32 (ret_addr=2142912231) at relay.c:599
#25 0x7f71a3a1 in __wine_spec_exp_ordinals () from
/opt/cfw/wine/lib/wine/x11drv.dll.so
#26 0x7fba4554 in CreateWindowExA (exStyle=256, className=0x7fd8e538 IEFrame,
windowName=0x7fd8e74c Microsoft Internet Explorer, style=47120384,
x=-2147483648, y=-2147483648, width=-2147483648,
height=-2147483648, parent=0x0, menu=0x94, instance=0x7116,
Wine no longer compiles
Haven't been able to compile cvs wine for the last few weeks. This is Fedora Rawhide with gcc4. Any suggestions? gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.o file.c In file included from ../../../include/winnt.h:27, from ../../../include/windef.h:204, from ../../../include/wine/test.h:25, from file.c:21: ../../../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function iswalnum ../../../include/msvcrt/ctype.h:73: warning: conflicting types for built-in function iswalpha ../../../include/msvcrt/ctype.h:75: warning: conflicting types for built-in function iswcntrl ../../../include/msvcrt/ctype.h:77: warning: conflicting types for built-in function iswdigit ../../../include/msvcrt/ctype.h:78: warning: conflicting types for built-in function iswgraph ../../../include/msvcrt/ctype.h:79: warning: conflicting types for built-in function iswlower ../../../include/msvcrt/ctype.h:80: warning: conflicting types for built-in function iswprint ../../../include/msvcrt/ctype.h:81: warning: conflicting types for built-in function iswpunct ../../../include/msvcrt/ctype.h:82: warning: conflicting types for built-in function iswspace ../../../include/msvcrt/ctype.h:83: warning: conflicting types for built-in function iswupper ../../../include/msvcrt/ctype.h:84: warning: conflicting types for built-in function iswxdigit ../../../include/msvcrt/ctype.h:85: warning: conflicting types for built-in function towlower ../../../include/msvcrt/ctype.h:86: warning: conflicting types for built-in function towupper ../../../include/msvcrt/io.h:179: error: open aliased to external symbol _open ../../../include/msvcrt/io.h:180: error: sopen aliased to undefined symbol _sopen ../../../include/msvcrt/process.h:129: error: execl aliased to undefined symbol _execl ../../../include/msvcrt/process.h:130: error: execle aliased to undefined symbol _execle ../../../include/msvcrt/process.h:131: error: execlp aliased to undefined symbol _execlp ../../../include/msvcrt/process.h:132: error: execlpe aliased to undefined symbol _execlpe ../../../include/msvcrt/process.h:133: error: spawnl aliased to undefined symbol _spawnl ../../../include/msvcrt/process.h:134: error: spawnle aliased to undefined symbol _spawnle ../../../include/msvcrt/process.h:135: error: spawnlp aliased to undefined symbol _spawnlp ../../../include/msvcrt/process.h:136: error: spawnlpe aliased to undefined symbol _spawnlpe -- Ivan Gyurdiev [EMAIL PROTECTED] Cornell University
More problems in ie6
In addition to the bad process handle I get intermittent crashes in IE6 which seems to be due to the creation of more than 8 threads or when a thread is ended (IE it occurs after thread 8 starts, then exits then another thread 8 starts (9th thread creation)) Thread 8 is the first thread that actually exited in the program. Are there any resource limits to per process thread creation in wine ? This seems to lead to a crash in temp_stacks +111 but temp stacks should not hold any executable code. The web site that seems to tickle this problem is www.gamedude.com.au Any Guesses anyone ? Bob
RE: WoW, er Wine on Windows--Re: Still more fun?
Augustus Saunders wrote: As for what we hope to accomplish, well, it might seem like massive overkill to try using WINE, but it's the only plausible way I've come up with. Basically, we want to substitute all the graphics/windowing/GDI etc so that we can record all the painting/rendering into some kind of WMF type thingy. The idea is to get screen captures as metafiles that are perfectly screen-accurate. There are numerous ways to grab a bitmap rendering of a window/screen, but that's useless. Also, you can (sometimes) get an application to print to your metafile, but that is for printing documents and does not show the application as it appears on screen. The end result? Essentially vector graphic screen shots. I think what you are trying to do is actually API hooking. There are ways to do that as explained in older MS System Journals and most probably also on www.sysinternals.com. Alternatively I'm quite sure there is already some mechanisme built into Windows to do that. Two possible things come to my mind. If you make a screen capture with the Print Screen key, Windows seems to place a WMF or EMF format onto the clipboard already. And WMF/EMF is basically nothing more than a stream of GDI opcodes and its parameters as they are passed to the according GDI function. Alternatively you might want to look at how some of the recorder application do their work. I believe that there used to be a MSDN sample screen recorder application which might give you a start on how to do these things. Using Wine for this is most probably not very effective. You don't want to have DLLs reimplementing GDI and other low level Windows systems, and only forwarding all calls to the real system DLLs would mean modifying the Wine code to such an amount that Writing that code from scratch might be actually simpler. Rolf Kalbermatter
Re: Odd problem with process handles
Hi Bob,
hModule is 0xe and gets dereferenced to find e_magic
presumably from the psp.
Could you try the following really quick patch? I have no idea where the
-1 value to GetProcAddress comes from, LoadLibraryA returned NULL. I'm
also not sure whether the check belongs in here or in GetProcAddress. But
this might let it get further for you.
Index: dlls/ntdll/loader.c
===
RCS file: /home/wine/wine/dlls/ntdll/loader.c,v
retrieving revision 1.87
diff -u -r1.87 loader.c
--- dlls/ntdll/loader.c 21 Mar 2005 10:52:26 - 1.87
+++ dlls/ntdll/loader.c 24 Apr 2005 17:09:39 -
@@ -2017,6 +2017,8 @@
const IMAGE_NT_HEADERS *nt;
DWORD addr;
+if ( module == (HMODULE)-1 )
+return NULL;
if ((ULONG_PTR)module 1) /* mapped as data file */
{
module = (HMODULE)((ULONG_PTR)module ~1);
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Some fixes for filtergraph.c (#2)
This is not correct, you must connect all pins, not just the first
that succeeds.
Asleep? ;) You can't connect an input pin more then once
(VFW_E_ALREADY_CONNECTED), anyway this function always returned S_OK,
I fixed that too now... If you still think multiple connects should
happen
http://msdn.microsoft.com/library/en-us/directshow/htm/ipinconnect.asp ;)
No, no. It's not necessary. I'm convinced. :-)
static HRESULT WINAPI Mediacontrol_Pause(IMediaControl *iface) {
ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface);
+TRACE((%p/%p)-()\n, This, iface);
-TRACE((%p/%p)-(): stub !!!\n, This, iface);
+if (This-state == State_Paused) return S_OK;
+
+SendTheFilterAMessage(iface, SendPause);
+This-state = State_Paused;
return S_OK;
}
Shouldn't S_FALSE be returned in the last statement?
static HRESULT WINAPI Mediacontrol_Stop(IMediaControl *iface) {
ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface);
+TRACE((%p/%p)-()\n, This, iface);
-TRACE((%p/%p)-(): stub !!!\n, This, iface);
+if (This-state == State_Stopped) return S_OK;
+if (This-state == State_Running) SendTheFilterAMessage(iface, SendPause);
+SendTheFilterAMessage(iface, SendStop);
+This-state = State_Stopped;
return S_OK;
}
I think you should move the critical section out of
SendTheFilterAMessage and put it in Run, Pause and Stop methods.
Bye,
Christian
PS: SendTheFilterAMessage and FoundFilter are really odd names, no?
Re: Odd problem with process handles
Robert Lunnon wrote: I am having a problem with the attached segfault in ie6 I have attached a gdb backtrace and the last part of a relay dump. hModule is 0xe and gets dereferenced to find e_magic presumably from the psp. Obviously dereferencing 0xfffe is not good which raises an exception The exception is caught and appears to be ignored the first time it occurs but this seems unusual to me Can anyone shed light on this, is this normal or do I have a problem. What's going on here ? This is normal. IE expects a DLL (apphelp.dll?) to be loaded at the point where it does the GetProcAddress and it doesn't do any checking on the return value from GetModuleHandle. As there is an exception handler in RtlImageNtHeader it shouldn't crash IE and it should fail gracefully. Rob
Re: Installing Mozilla
Juan == Juan Lang [EMAIL PROTECTED] writes: Juan Alex wrote: I'm encountering a crash when trying to install Mozilla 1.7.7 under wine. I am using a fresh CVS checkout, but I've tried older revisions with the same result. Juan So far, this evidence points to a bug in Mozilla rather than in Juan Wine. It may very well be triggered by a bug in Wine.. Is the Mozilla Installer Installshield or MSI based? Otherwise is it open source? Perhaps an easier way to backtrace the problem? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Debugging with GDB [was: Re: World of Warcraft - crash in game]
On Sun, Apr 24, 2005 at 09:23:22AM +1000, Troy Rollo wrote: On Saturday 23 April 2005 22:12, Alex Woods wrote: I'm attaching to the process with gdb, but it's not catching things at the point where they go wrong. Typically I am just seeing a stack like this though: #0 0x56752a01 in ?? () If it's only giving one frame in the stack trace the cause is normally a corrupted stack, so you may need to examine the stack to try to figure out where the stack frame should be (starting with x/256xw may be helpful if the stack pointer is still valid). Yeah, the stack always looks in pretty bad shape. The address of the #0 frame has been within nvidia's libGLCore.so.1 everytime I've had a SIGSEGV. Other times when an exception is caught by WoW, it often comes back with an Out of memory message from one of it's files - off the top of my head MapMem.cpp, SFile.cpp and Texture.cpp. I don't think it's a problem with the nvidia driver since it handles doom3 just fine. I do think it's a problem around the OpenGL space though, because turning down the graphical options makes the game stable. I might try playing with the options to see if any particular one is the cause. Otherwise, when debugging with GDB without going through winedbg you may need to use the pass command to skip over first chance exceptions in some cases before you get to the real exception. I'm not sure I'm seeing the first chance exceptions at all until - I presume these are exceptions that are raised but are expected to some extent and so are handled without stopping execution? I just seem to be seeing signals telling the thread it's been suspended I think. I'm not clear on how wine handles exceptions though. Cheers. -- Alex
Re: Installing Mozilla
--- Uwe Bonnes [EMAIL PROTECTED] wrote: Is the Mozilla Installer Installshield or MSI based? Otherwise is it open source? Perhaps an easier way to backtrace the problem? I believe it's open source. The crash was due to Mozilla attempting to write to a value that's exported by msvcrt.dll. It was declared in msvcrt's spec file, but never defined. Thus Mozilla was writing to a garbage pointer. It's been fixed in Wine. There's a separate issue that Mozilla probably isn't doing the right thing. It's overwriting a buffer it doesn't own and whose size is not documented, and it should be writing only four characters but is writing more. Now that Wine is fixed this is unlikely to cause anyone any trouble, but it's still not right. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Installing Mozilla
I was going to file the bug with mozilla, but I wasnt sure of how to describe it.. sorry..now I know, but dont know how to describe where it is.. would bug in ntmisc.c: _tzname be appropriate? Dustin Juan Lang wrote: --- Uwe Bonnes [EMAIL PROTECTED] wrote: Is the Mozilla Installer Installshield or MSI based? Otherwise is it open source? Perhaps an easier way to backtrace the problem? I believe it's open source. The crash was due to Mozilla attempting to write to a value that's exported by msvcrt.dll. It was declared in msvcrt's spec file, but never defined. Thus Mozilla was writing to a garbage pointer. It's been fixed in Wine. There's a separate issue that Mozilla probably isn't doing the right thing. It's overwriting a buffer it doesn't own and whose size is not documented, and it should be writing only four characters but is writing more. Now that Wine is fixed this is unlikely to cause anyone any trouble, but it's still not right. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
PATCH: gcc4 alias fixes
Hi,
This is the patch I use for gcc4.0 here.
I am not really sure why this aliasing was introduced,
but it will not work this way anymore.
Ciao, Marcus
diff -ruN -x CVS wine-20050419/include/msvcrt/conio.h
marcus-wine-20050419/include/msvcrt/conio.h
--- wine-20050419/include/msvcrt/conio.h2004-07-19 13:07:44.0
+0200
+++ marcus-wine-20050419/include/msvcrt/conio.h 2005-04-13 13:03:23.0
+0200
@@ -53,7 +53,7 @@
static inline unsigned short outpw(unsigned short i, unsigned short j) {
return _outpw(i, j); }
#endif
-#ifdef __GNUC__
+#if defined(__GNUC__) (__GNUC__ 4)
extern int cprintf(const char*,...)
__attribute__((alias(_cprintf),format(printf,1,2)));
extern int cscanf(const char*,...)
__attribute__((alias(_cscanf),format(scanf,1,2)));
#else
diff -ruN -x CVS wine-20050419/include/msvcrt/io.h
marcus-wine-20050419/include/msvcrt/io.h
--- wine-20050419/include/msvcrt/io.h 2004-07-19 13:07:44.0 +0200
+++ marcus-wine-20050419/include/msvcrt/io.h2005-04-13 13:03:23.0
+0200
@@ -175,7 +175,7 @@
#endif
static inline int write(int fd, const void* buf, unsigned int size) { return
_write(fd, buf, size); }
-#ifdef __GNUC__
+#if defined(__GNUC__) (__GNUC__ 4)
extern int open(const char*,int,...) __attribute__((alias(_open)));
extern int sopen(const char*,int,int,...) __attribute__((alias(_sopen)));
#else
diff -ruN -x CVS wine-20050419/include/msvcrt/process.h
marcus-wine-20050419/include/msvcrt/process.h
--- wine-20050419/include/msvcrt/process.h 2004-07-19 13:07:44.0
+0200
+++ marcus-wine-20050419/include/msvcrt/process.h 2005-04-13
13:03:23.0 +0200
@@ -125,7 +125,7 @@
static inline int spawnvp(int flags, const char* name, const char* const*
argv) { return _spawnvp(flags, name, argv); }
static inline int spawnvpe(int flags, const char* name, const char* const*
argv, const char* const* envv) { return _spawnvpe(flags, name, argv, envv); }
-#ifdef __GNUC__
+#if defined(__GNUC__) (__GNUC__ 4)
extern int execl(const char*,const char*,...) __attribute__((alias(_execl)));
extern int execle(const char*,const char*,...)
__attribute__((alias(_execle)));
extern int execlp(const char*,const char*,...)
__attribute__((alias(_execlp)));
pgpmW8D8PmwoK.pgp
Description: PGP signature
Re: PATCH: gcc4 alias fixes
On Sun, Apr 24, 2005 at 10:02:47PM +0200, Marcus Meissner wrote: Hi, This is the patch I use for gcc4.0 here. I am not really sure why this aliasing was introduced, but it will not work this way anymore. I still don't understand why it doesn't work. It was introduced because using macros it not always acceptable. Some source uses these functions in ways that break if they are defined as macros. Defining them as inline functions work, but we can't do so for varargs, in which case we used aliases. What was the reason to break them, and why they don't work? They are aliasing to things that _are_ defined, so I'm not sure what is going on there. -- Dimi.
writejump purpose
In kthread.c there is this code that is only defined for I386 glibc, but the
solaris port uses Solaris libc so the function does nothing. What is the
purpose of this function and exactly what should the semantics be ?
BOb
static inline void writejump( const char *symbol, void *dest )
{
#if defined(__GLIBC__) defined(__i386__)
unsigned char *addr = wine_dlsym( RTLD_NEXT, symbol, NULL, 0 );
if (!addr) return;
/* write a relative jump at the function address */
mprotect((void*)((unsigned int)addr ~(getpagesize()-1)), 5, PROT_READ|
PROT_EXEC|PROT_WRITE);
addr[0] = 0xe9;
*(int *)(addr+1) = (unsigned char *)dest - (addr + 5);
mprotect((void*)((unsigned int)addr ~(getpagesize()-1)), 5, PROT_READ|
PROT_EXEC);
# ifdef HAVE_VALGRIND_MEMCHECK_H
VALGRIND_DISCARD_TRANSLATIONS( addr, 5 );
# endif
#endif /* __GLIBC__ __i386__ */
}
Re: Wine no longer compiles
On 4/24/05, Ivan Gyurdiev [EMAIL PROTECTED] wrote: Haven't been able to compile cvs wine for the last few weeks. This is Fedora Rawhide with gcc4. Any suggestions? gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.o file.c In file included from ../../../include/winnt.h:27, from ../../../include/windef.h:204, from ../../../include/wine/test.h:25, from file.c:21: ../../../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function 'iswalnum' ../../../include/msvcrt/ctype.h:73: warning: conflicting types for built-in function 'iswalpha' ../../../include/msvcrt/ctype.h:75: warning: conflicting types for built-in function 'iswcntrl' ../../../include/msvcrt/ctype.h:77: warning: conflicting types for built-in function 'iswdigit' ../../../include/msvcrt/ctype.h:78: warning: conflicting types for built-in function 'iswgraph' ../../../include/msvcrt/ctype.h:79: warning: conflicting types for built-in function 'iswlower' ../../../include/msvcrt/ctype.h:80: warning: conflicting types for built-in function 'iswprint' ../../../include/msvcrt/ctype.h:81: warning: conflicting types for built-in function 'iswpunct' ../../../include/msvcrt/ctype.h:82: warning: conflicting types for built-in function 'iswspace' ../../../include/msvcrt/ctype.h:83: warning: conflicting types for built-in function 'iswupper' ../../../include/msvcrt/ctype.h:84: warning: conflicting types for built-in function 'iswxdigit' ../../../include/msvcrt/ctype.h:85: warning: conflicting types for built-in function 'towlower' ../../../include/msvcrt/ctype.h:86: warning: conflicting types for built-in function 'towupper' ../../../include/msvcrt/io.h:179: error: 'open' aliased to external symbol '_open' ../../../include/msvcrt/io.h:180: error: 'sopen' aliased to undefined symbol '_sopen' ../../../include/msvcrt/process.h:129: error: 'execl' aliased to undefined symbol '_execl' ../../../include/msvcrt/process.h:130: error: 'execle' aliased to undefined symbol '_execle' ../../../include/msvcrt/process.h:131: error: 'execlp' aliased to undefined symbol '_execlp' ../../../include/msvcrt/process.h:132: error: 'execlpe' aliased to undefined symbol '_execlpe' ../../../include/msvcrt/process.h:133: error: 'spawnl' aliased to undefined symbol '_spawnl' ../../../include/msvcrt/process.h:134: error: 'spawnle' aliased to undefined symbol '_spawnle' ../../../include/msvcrt/process.h:135: error: 'spawnlp' aliased to undefined symbol '_spawnlp' ../../../include/msvcrt/process.h:136: error: 'spawnlpe' aliased to undefined symbol '_spawnlpe' Edit the respective files containing the errors (ie wine/include/msvcrt/process.h) and #if 0 define out all the aliases. Apparently these aren't needed because everything works fine without them, but who knows. -- James Hawkins
Re: Installing Mozilla
Was it the Mozilla installer that was crashing due to a bug in it's ntmisc.c or the Mozilla app itself that was crashing? Dustin Juan Lang wrote: --- Uwe Bonnes [EMAIL PROTECTED] wrote: Is the Mozilla Installer Installshield or MSI based? Otherwise is it open source? Perhaps an easier way to backtrace the problem? I believe it's open source. The crash was due to Mozilla attempting to write to a value that's exported by msvcrt.dll. It was declared in msvcrt's spec file, but never defined. Thus Mozilla was writing to a garbage pointer. It's been fixed in Wine. There's a separate issue that Mozilla probably isn't doing the right thing. It's overwriting a buffer it doesn't own and whose size is not documented, and it should be writing only four characters but is writing more. Now that Wine is fixed this is unlikely to cause anyone any trouble, but it's still not right.
Re: writejump purpose
On Mon, Apr 25, 2005 at 07:59:30AM +1000, Robert Lunnon wrote: In kthread.c there is this code that is only defined for I386 glibc, but the solaris port uses Solaris libc so the function does nothing. What is the purpose of this function and exactly what should the semantics be ? It is overwriting the __errno_location() handler in libc with a WINE threadsafe one. I am not sure whether Solaris needs it. Ciao, Marcus
