Re: dlls/wined3d/device.c GetCreationParameters
Aric Cyr wrote:
Al Tobey tobert at gmail.com writes:
Here is the new patch. I did some additional testing and couldn't
get the same app to fail on that function again. It still works with
this new patch, so I'm assuming for now that it's correct.Anyways,
thanks again.
Hi Al,
Almost got it this time :)
You should be checking that pParameters is not NULL, not This-createParms.
Note that if This is not-NULL, This-creatParms will be not null as well since
you are just getting the address of a struct. Also on failure, according to
MSDN, you shoudl be returning D3DERR_INVALIDCALL not OUTOFVIDEOMEMORY.
Probably the following would be most correct:
---
{
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface;
if (This == NULL || pParameters == NULL)
This should never be NULL as where did the application get the address
of the function from?
--
Rob Shearman
Re: [rpcrt4] Properly created named pipes
Thomas Weidenmueller wrote: Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise the call to ConnectNamedPipe() will block the server thread if no connection can be established, which causes the rpc server to dead-lock during startup. Hi Thomas, I have a patch that converts rpcrt4 over to using overlapped I/O, but I didn't submit it because the performance on Wine is horrible. When using overlapped I/O we have to perform several more server calls than when using non-overlapped I/O. Also, I think that this patch is incorrect because if you want to make the pipe overlapped then you have to fix up all of the ReadFile calls to take an OVERLAPPED structure. I'll shortly be starting a rewrite of part of the RPC server so that we can support more transports and I'll bear this bug in mind when I do it and I'll try to fix it. The solution I come to will probably involve a worker thread doing the ConnectNamedPipe. -- Rob Shearman
Re: dlls/wined3d/device.c GetCreationParameters
On 17/01/06, Robert Shearman [EMAIL PROTECTED] wrote: This should never be NULL as where did the application get the address of the function from? Well, The function could be called directly from inside wined3d, or the application could store the address somewhere. Something along the lines of: some_function_ptr = object1-lpVtbl-GetCreationParameters; some_function_ptr(object1, parameters); some_function_ptr(object2, parameters); However, in either case you probably want to fail hard and get a backtrace.
Re: [rpcrt4] Properly created named pipes
Robert Shearman wrote: I have a patch that converts rpcrt4 over to using overlapped I/O, but I didn't submit it because the performance on Wine is horrible. When using overlapped I/O we have to perform several more server calls than when using non-overlapped I/O. Also, I think that this patch is incorrect because if you want to make the pipe overlapped then you have to fix up all of the ReadFile calls to take an OVERLAPPED structure. That's true, the ReadFile calls would also have to use the OVERLAPPED structure, but that would only work if the pipes were created with the PIPE_NOWAIT flag. Otherwise ReadFile and WriteFile will (or better should) be still synchronous regardless of the FILE_FLAG_OVERLAPPED flag. I'll shortly be starting a rewrite of part of the RPC server so that we can support more transports and I'll bear this bug in mind when I do it and I'll try to fix it. The solution I come to will probably involve a worker thread doing the ConnectNamedPipe. I hope the code gets fixed before the next wine release, because rpcrt4 currently deadlocks (or should deadlock) when starting a server (at least in ROS/Win). P.S. With WINE 0.9.5's implementation I noticed a massive thread leak on server-side (one thread per request?), is this a known bug? - Thomas
Re: dlls/wined3d/device.c GetCreationParameters
H. Verbeet hverbeet at gmail.com writes: On 17/01/06, Robert Shearman rob at codeweavers.com wrote: This should never be NULL as where did the application get the address of the function from? Well, The function could be called directly from inside wined3d, or the application could store the address somewhere. However, in either case you probably want to fail hard and get a backtrace. Ya, I thought about that after I sent my previous mail as well... an assert would probably be more useful for checking This. I also disagree that This is guaranteed to always be non-NULL. There really is no way you can force policy how a user calls the function, so minimally checking (or aborting) on NULL is a sane thing to do. It doesn't hurt the code, and catches potential usage problems. Regards, Aric
Re: dlls/wined3d/device.c GetCreationParameters
Aric Cyr [EMAIL PROTECTED] writes: Ya, I thought about that after I sent my previous mail as well... an assert would probably be more useful for checking This. I also disagree that This is guaranteed to always be non-NULL. There really is no way you can force policy how a user calls the function, so minimally checking (or aborting) on NULL is a sane thing to do. It doesn't hurt the code, and catches potential usage problems. Not checking at all and crashing works just as well to catch problems, and doesn't hurt performance. There's no reason to add NULL checks unless there is a Windows app that depends on it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: dlls/wined3d/device.c GetCreationParameters
Hi, On Tue, Jan 17, 2006 at 11:16:42AM +0100, Alexandre Julliard wrote: Aric Cyr [EMAIL PROTECTED] writes: Ya, I thought about that after I sent my previous mail as well... an assert would probably be more useful for checking This. I also disagree that This is guaranteed to always be non-NULL. There really is no way you can force policy how a user calls the function, so minimally checking (or aborting) on NULL is a sane thing to do. It doesn't hurt the code, and catches potential usage problems. Not checking at all and crashing works just as well to catch problems, and doesn't hurt performance. There's no reason to add NULL checks unless there is a Windows app that depends on it. Exactly! Stupid NULL pointer checks even actively hurt debugging since in severe cases you may have a function properly (*cough*) failing due to a NULL pointer check, but then unfortunately you notice the effect of this properly checked anomaly only 3 layers and 5000 relay log lines later when something almost entirely unrelated really breaks with a SEGV. Have fun wasting the time to trace back those 3 layers to the real offender... Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Re: [rpcrt4] Properly created named pipes
Thomas Weidenmueller wrote: Robert Shearman wrote: I have a patch that converts rpcrt4 over to using overlapped I/O, but I didn't submit it because the performance on Wine is horrible. When using overlapped I/O we have to perform several more server calls than when using non-overlapped I/O. Also, I think that this patch is incorrect because if you want to make the pipe overlapped then you have to fix up all of the ReadFile calls to take an OVERLAPPED structure. That's true, the ReadFile calls would also have to use the OVERLAPPED structure, but that would only work if the pipes were created with the PIPE_NOWAIT flag. Otherwise ReadFile and WriteFile will (or better should) be still synchronous regardless of the FILE_FLAG_OVERLAPPED flag. I'll shortly be starting a rewrite of part of the RPC server so that we can support more transports and I'll bear this bug in mind when I do it and I'll try to fix it. The solution I come to will probably involve a worker thread doing the ConnectNamedPipe. I hope the code gets fixed before the next wine release, because rpcrt4 currently deadlocks (or should deadlock) when starting a server (at least in ROS/Win). If what you say is true about the PIPE_NOWAIT flag affecting this then it should be easy to fix. P.S. With WINE 0.9.5's implementation I noticed a massive thread leak on server-side (one thread per request?), is this a known bug? No. I'm pretty sure that the code works correctly and doesn't leak threads in Wine. If you can get a backtrace of the threads that shouldn't be around then I might be able to determine what is going wrong. -- Rob Shearman
Re: WINED3D: [02/02] IWineD3DSurfaceImpl_SetContainer IWineD3DVolumeImpl_SetContainer refcount fixes.
What is wrong with this patch / what can I do to fix it?
Re: dlls/wined3d/device.c GetCreationParameters
Andreas Mohr andi at rhlx01.fht-esslingen.de writes: On Tue, Jan 17, 2006 at 11:16:42AM +0100, Alexandre Julliard wrote: Aric Cyr Aric.Cyr at gmail.com writes: Ya, I thought about that after I sent my previous mail as well... an assert would probably be more useful for checking This. Not checking at all and crashing works just as well to catch problems, and doesn't hurt performance. There's no reason to add NULL checks unless there is a Windows app that depends on it. Stupid NULL pointer checks even actively hurt debugging since in severe cases you may have a function properly (*cough*) failing due to a NULL pointer check, but then unfortunately you notice the effect of this properly checked anomaly only 3 layers and 5000 relay log lines later when something almost entirely unrelated really breaks with a SEGV. Have fun wasting the time to trace back those 3 layers to the real offender... I'd have to (and did) agree that the NULL check for This wasn't a great idea, and thus suggested an assert. However, as wine does have a built in debugger, even that would really be unnecessary (as Alexandre pointed out), and crashing on the access would be just as good. I personally like asserts for getting debug info without needing to fire up a debugger since it is not always easy to reproduce a problem, especially when you aren't expecting any (and please no one suggest that I always launch all my apps with gdb... ;) Cheers, Aric
[rpcrt4] Properly created named pipes
Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise the call to ConnectNamedPipe() will block the server thread if no connection can be established, which causes the rpc server to dead-lock during startup. - Thomas Index: dlls/rpcrt4/rpc_binding.c === RCS file: /home/wine/wine/dlls/rpcrt4/rpc_binding.c,v retrieving revision 1.39 diff -u -r1.39 rpc_binding.c --- dlls/rpcrt4/rpc_binding.c 6 Sep 2005 10:26:14 - 1.39 +++ dlls/rpcrt4/rpc_binding.c 16 Jan 2006 23:00:15 - @@ -142,7 +142,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection-Endpoint) + 1); strcat(strcpy(pname, prefix), Connection-Endpoint); TRACE(listening on %s\n, pname); -Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, +Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname); @@ -166,7 +166,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection-Endpoint) + 1); strcat(strcpy(pname, prefix), Connection-Endpoint); TRACE(listening on %s\n, pname); -Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, +Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname);
Mandriva problems
Have asked this question to several news groups without getting any response. Was suggested that I submit it to you Krister Hallergard Lytham UK Have problems to install quite a few programs with wine - Mandriva 2006 that I can install without problems with other distros (SuSE10.0, Fedora C4 and Kubuntu 5.10) on other partitions on the same machine. My main interest is to install Excel 97 to be able to acces my old wk4-files (I know I can convert them to xls-files to use with Open Office, but I dont want to do that, as I can install Excel on SuSE. Why is Mandriva so difficult?? Made a fresh Madriva installation and as first thing installed wine 0.9.5. When trying to install Excel 97 I get these error messages QUOTE: [EMAIL PROTECTED] disk1]$ wine install.exe wine: Unhandled exception (thread 000a), starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c005 flags 0 addr 0x7faa3b93 UNQUOTE Next I applied the suggestions in Frank´s corner to install Excel 97 and get this long debug message: QUOTE: [EMAIL PROTECTED] disk1]$ WINEDLLOVERRIDES=odccp32=n wine INSTALL.EXE wine: Unhandled page fault on read access to 0x7fdd1a0a at address 0x11df:0x001a (thread 000a), starting debugger... WineDbg starting on pid 0x8 fixme:dbghelp:SymLoadModule Should have successfully loaded debug information for image Z:\mnt\cdrom\DISK1\INSTALL.EXE Unhandled exception: page fault on read access to 0x7fdd1a0a in 16-bit code (11df:001a). In 16 bit mode. Register dump: CS:11df SS:11ef DS:11ef ES:11c7 FS:003b GS:0033 IP:001a SP:5964 BP: FLAGS:0202( - 00 - -RI1) AX: BX:2400 CX:0800 DX: SI: DI:11ee Stack dump: 0x11ef:0x5964: 046c 101f 0x11ef:0x5974: 0x11ef:0x5984: 023d: sel=11ef base=7fde0f20 limit=619f 16-bit rw- 0238: sel=11c7 base=7fdc1690 limit=010f 16-bit rw- Backtrace: =1 0x11df:0x001a (0x11df:0x001a) 0x11df:0x001a: xorw %bp,%bp Modules: Module Address Debug info Name (69 modules) ELF 0x7be82000-7bf0 Deferredntdllelf \-PE 0x7be9-7bf0 \ ntdll ELF 0x7bf0-7bf03000 Deferredwine-loader ELF 0x7eef7000-7ef2b000 Deferreduxthemeelf \-PE 0x7ef0-7ef2b000 \ uxtheme ELF 0x7ef2b000-7eff9000 Deferredcomctl32elf \-PE 0x7ef3-7eff9000 \ comctl32 ELF 0x7eff9000-7f018000 Deferrediphlpapielf \-PE 0x7f00-7f018000 \ iphlpapi ELF 0x7f018000-7f06 Deferredrpcrt4elf \-PE 0x7f03-7f06 \ rpcrt4 ELF 0x7f06-7f0f9000 Deferredole32elf \-PE 0x7f08-7f0f9000 \ ole32 ELF 0x7f0f9000-7f158000 Deferredshlwapielf \-PE 0x7f11-7f158000 \ shlwapi ELF 0x7f158000-7f22b000 Deferredshell32elf \-PE 0x7f17-7f22b000 \ shell32 ELF 0x7f22b000-7f23f000 Deferredlz32elf \-PE 0x7f23-7f23f000 \ lz32 ELF 0x7f36b000-7f38 Deferredmidimapelf \-PE 0x7f37-7f38 \ midimap ELF 0x7f492000-7f4b6000 Deferredmsacm32elf \-PE 0x7f4a-7f4b6000 \ msacm32 ELF 0x7f4b6000-7f4cf000 Deferredmsacmelf \-PE 0x7f4c-7f4cf000 \ msacm ELF 0x7f4cf000-7f517000 Deferredwineosself \-PE 0x7f4e-7f517000 \ wineoss ELF 0x7f517000-7f59e000 Deferredwinmmelf \-PE 0x7f52-7f59e000 \ winmm ELF 0x7f59e000-7f601000 Deferredwinedoself \-PE 0x7f5b-7f601000 \ winedos ELF 0x7f601000-7f60a000 Deferredlibxcursor.so.1 ELF 0x7f60a000-7f627000 Deferredimm32elf \-PE 0x7f61-7f627000 \ imm32 ELF 0x7f627000-7f644000 Deferredximcp.so.2 ELF 0x7f644000-7f6ae000 Deferredlibgl.so.1 ELF 0x7f6ae000-7f77a000 Deferredlibx11.so.6 ELF 0x7f77a000-7f792000 Deferredlibice.so.6 ELF 0x7f792000-7f81c000 Deferredwinex11elf \-PE 0x7f7a-7f81c000 \ winex11 ELF 0x7f81c000-7f83c000 Deferredlibexpat.so.0 ELF 0x7f83c000-7f86c000 Deferredlibfontconfig.so.1 ELF 0x7f86c000-7f87f000 Deferredlibz.so.1 ELF 0x7f87f000-7f8e8000 Deferredlibfreetype.so.6 ELF 0x7f8fd000-7f93f000 Deferredadvapi32elf \-PE 0x7f91-7f93f000 \ advapi32 ELF 0x7f93f000-7f9d4000 Deferredgdi32elf \-PE 0x7f95-7f9d4000 \ gdi32 ELF 0x7f9d4000-7fb1 Deferreduser32elf \-PE 0x7f9f-7fb1 \ user32 ELF
Re: [rpcrt4] Properly created named pipes
Robert Shearman wrote: Thomas Weidenmueller wrote: If what you say is true about the PIPE_NOWAIT flag affecting this then it should be easy to fix. The PIPE_NOWAIT flag is documented in the PSDK. In fact, named pipes are handled slightly differently in ReadFile/WriteFile. Even if the named pipe was created with FILE_FLAG_OVERLAPPED the connect, read write operations are still performed synchronously, unless the pipe was created with PIPE_NOWAIT. This is because named pipes are handled differently to other devices and it's up to the npfs driver to decide whether to perform the operation synchronously or not (by checking for PIPE_NOWAIT, which is internally mapped to FILE_PIPE_COMPLETE_OPERATION). So all in all, my patch in fact isn't quite correct because the PIPE_NOWAIT flag would be necessary. No. I'm pretty sure that the code works correctly and doesn't leak threads in Wine. If you can get a backtrace of the threads that shouldn't be around then I might be able to determine what is going wrong. Ok, then I guess it's the pipe implementation in ROS that causes this handle leak. - Thomas
GIT rebase changes
Hi GIT users, The GIT guys have made rebase and pull incompatible, and to use rebase (which is likely what we want to do for Wine), you must use fetch then rebase, not pull (which does a merge). See: http://article.gmane.org/gmane.linux.kernel/365410 The error message that you get if you use pull then try to rebase with newer version of GIT is pretty useless: bash-3.00$ git-rebase origin Current branch refs/heads/master is up to date. So use git-fetch to update origin, then git-rebase origin after that to get the new changes. I've update the Wiki with that information - don't shoot the messenger :/ Mike
Unixfs as ShellFSFolder?
Hi all,
I guess I'm responsible for a lot of redundant code between the
implementations of filesystem shellfolders in shell32/shlfdr_fs.c and
shfldr_unixfs.c. While I've always tried to re-use as much code as possible,
unixfs by nature has to use posix apis to get hold of the unix filesystem.
In current cvs, unixfs can be used as a drop-in replacement for the old
CLSID_ShellFSFolder implementation and if you apply the attached small patch,
it will be. It would be nice if some people could try this in their local
tree and report problems with it.
What do people think about getting rid of shfldr_fs.c in the long run, in
order to remove the redundancy? Does ReactOS use wine's shell32.dll? I guess
it would be a problem for them?
ChangeLog:
shell32: Use shfldr_unixfs CLSID_ShellFSFolder implementation instead of the
one from shfldr_fs
dlls/shell32/shellole.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Bye,
--
Michael Jung
[EMAIL PROTECTED]
b4c74494324ef105c2ef224f7e4f24d0862ebb12
diff --git a/dlls/shell32/shellole.c b/dlls/shell32/shellole.c
index 9b92c26..5016196 100644
--- a/dlls/shell32/shellole.c
+++ b/dlls/shell32/shellole.c
@@ -64,7 +64,7 @@ struct {
REFIID riid;
LPFNCREATEINSTANCE lpfnCI;
} InterfaceTable[] = {
- {CLSID_ShellFSFolder, IFSFolder_Constructor},
+ {CLSID_ShellFSFolder, ShellFSFolder_Constructor},
{CLSID_MyComputer, ISF_MyComputer_Constructor},
{CLSID_ShellDesktop, ISF_Desktop_Constructor},
{CLSID_ShellLink, IShellLink_Constructor},
Re: GIT rebase changes
Hi! Mike McCormack wrote: The GIT guys have made rebase and pull incompatible, and to use rebase (which is likely what we want to do for Wine), you must use fetch then rebase, not pull (which does a merge). Depends if you want to keep your old history or not. git pull works nicely. See: http://article.gmane.org/gmane.linux.kernel/365410 The error message that you get if you use pull then try to rebase with newer version of GIT is pretty useless: I run into this yesterday. My master had the same code but different history than origin. Did a git rebase (after branching my master so i can keep my old history) and expected it to make master identical to origin. I know i can achieve the same by copying the origin head over to the master head but that would be like cheating. I'm still pondering what makes more sense: - to keep my old history, or - rebase to origin every now and then to easier spot the differences between master and origin. bash-3.00$ git-rebase origin Current branch refs/heads/master is up to date. So use git-fetch to update origin, then git-rebase origin after that to get the new changes. I've update the Wiki with that information - don't shoot the messenger :/ bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
RE: Unixfs as ShellFSFolder?
From: Michael Jung What do people think about getting rid of shfldr_fs.c in the long run, in order to remove the redundancy? Does ReactOS use wine's shell32.dll? I guess it would be a problem for them? Yes, we do and yes, it would be a problem... We don't import the shfldr_unixfs.c file because we have no use for it. I haven't really looked at the unixfs stuff, but I'm wondering if it's perhaps possible to use an inheritance mechanism? shfldr_fs and shfldr_unixfs could both inherit from a common implementation, we can tack on some internal routines to the existing vtable. Redundancy between the two can then be eliminated by extracting the common code to the base class which would call through the vtable to the internal routines. If this is only for the benefit of ReactOS then of course I would be willing to put in the work to make it happen. Gé van Geldorp.
Re: HW address w/o connection in iphlpapi
Juan, When you boot a linux box without an ethernet connection, and eth0 configuration fails, GetAdaptersInfo does not return MAC address info for eth0. The problem seems to be that enumerateInterfaces (in dlls/iphlpapi/ifenum.c) doesn't create a record for eth0, because SIOCGIFCONF doesn't return one. Mmm. Yeah, I think an alternative to SIOCGIFCONF might be the thing. getifaddrs is pretty nice, and it has the additional advantage that it can support IPv6, which SIOCGIFCONF does not. I'm not certain whether it returns down interfaces or not, but we can hope so. Unfortunately it's Dang. It doesn't work for down devices. When I run strace on a program that uses getifaddrs, the socket is opened with IPROTO_IP: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 14 ioctl(14, 0x8912, 0x2084d3a8) = 0 ioctl(14, 0x8912, 0x2084d3a8) = 0 ioctl(14, 0x8913, 0x7804ab38) = 0 ioctl(14, 0x891b, 0x7804ab38) = 0 ioctl(14, 0x8919, 0x7804ab38) = 0 ioctl(14, 0x8913, 0x7804ab58) = 0 ioctl(14, 0x891b, 0x7804ab58) = 0 ioctl(14, 0x8919, 0x7804ab58) = 0 Could it be that eth0 doesn't appear because it isn't configured for IP... that is, has no IP address? I can't figure out what these ioctls are either...? I'll keep digging, but if you have any clues I would love to hear them! I am shuffling in the dark here... mo PS: I've attached a diff file that implements getifaddrs for our Wine, 20050419. I didn't do the configure step, but put HAVE_IFADDRS_H in. Your code is left in if HAVE_IFADDRS_H is not defined. If you want, take it, check it out and adapt it to the current wine. ifenum.patch Description: Binary data
Benchmarks for 0.9.5
Hello, Please take with a large dose of salt. http://wiki.winehq.org/BenchMark-0.9.5 Tom -- Pain needs not cry for me...
Re: Benchmarks for 0.9.5
We appear to be faster now, leading in 67 tests vs. 63 for a previous set of benchmarks? Its difficult to see the trend over time having to go back and forth between pages. Chris On 1/17/06, Tom Wickline [EMAIL PROTECTED] wrote: Hello, Please take with a large dose of salt. http://wiki.winehq.org/BenchMark-0.9.5 Tom -- Pain needs not cry for me...
Re: winspool/tests: dump filename and version of the tested file
On 1/17/06, Detlef Riekenberg [EMAIL PROTECTED] wrote: Changelog: - winspool/tests: dump filename and version of the tested file - use name for all includes We generally have a policy of silence for the test suite unless a failure occurrs. Why do you need to output the version tested? -- James Hawkins
Re: Benchmarks for 0.9.5
On 1/17/06, Chris Morgan [EMAIL PROTECTED] wrote: We appear to be faster now, leading in 67 tests vs. 63 for a previous set of benchmarks? Its difficult to see the trend over time having to go back and forth between pages. Chris There is going to be a rather significant change taking place in a couple minutes. To make a long story short I was running 3dmark2000 in a 1024x768 window because when i selected details after a bench it would crash if I was in full screen.. I did some looking around and found a download http://www1.3dnews.ru/download/tests/3dmark/ There is a performance hit if you run the graphics test in a window.. I was going to put the new results next to the old wine results, but I re-ran some of the test on XP as well because wine will run the HDD test in pcmark04 now. I can put up a page with 20050419 results vs 0.9.5 ?? Tom
Re: GIT rebase changes
I hate to reply to myself, but ... Michael Stefaniuc wrote: Mike McCormack wrote: The GIT guys have made rebase and pull incompatible, and to use rebase (which is likely what we want to do for Wine), you must use fetch then rebase, not pull (which does a merge). Depends if you want to keep your old history or not. git pull works nicely. See: http://article.gmane.org/gmane.linux.kernel/365410 The error message that you get if you use pull then try to rebase with newer version of GIT is pretty useless: I run into this yesterday. My master had the same code but different history than origin. Did a git rebase (after branching my master so i can keep my old history) and expected it to make master identical to origin. I know i can achieve the same by copying the origin head over to the master head but that would be like cheating. I'm still pondering what makes more sense: - to keep my old history, or And this screws you up when you do git-format-patch. My VarCmp patches in my master tree where composed out of a ton of separate small patches (took me some time to have that function figured out) and now git-format-patch dumped those out too even that my master branch and origin where code wise the same. Quite annoying. - rebase to origin every now and then to easier spot the differences between master and origin. Mike, you were right, git rebase is what we want to use. But if you do not have patches sent to upstream git pull works too and it's faster to type. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Benchmarks for 0.9.5
On 1/17/06, Tom Wickline [EMAIL PROTECTED] wrote: Hello, Please take with a large dose of salt. http://wiki.winehq.org/BenchMark-0.9.5 Add more salt, I have the 3dmark2000 result browser installed and can get scores from full screen runs now. Tom
Re: Benchmarks for 0.9.5
From: Tom Wickline [EMAIL PROTECTED] I was going to put the new results next to the old wine results, but I re-ran some of the test on XP as well because wine will run the HDD test in pcmark04 now. I can put up a page with 20050419 results vs 0.9.5 ?? That would be great, but please don't create another page. Just add one more column at the end (that would hold just the percentage difference of the old test), and put N/A for tests that were not run/available in 20050419. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
winspool/tests: a Space before the printername is invalid
Am Dienstag, den 17.01.2006, 13:08 -0600 schrieb Wine Bugs:
--- Additional Comments From [EMAIL PROTECTED] 2006-17-01 13:08 ---
And to make it complete, space before printer name in customized printing
dialog
is still present.
(mayby small bug in ISS?)
This Patch validates, that the failure of OpenPrinter is not
a wine Problem.
Win9x: ERROR_INVALID_PARAMETER
WinNT: ERROR_INVALID_PRINTER_NAME
Changelog:
- winspool/tests: a Space before the printername is invalid
--
By By ...
... Detlef
diff --git a/dlls/winspool/tests/info.c b/dlls/winspool/tests/info.c
index 2218ef4..a970c5e 100644
--- a/dlls/winspool/tests/info.c
+++ b/dlls/winspool/tests/info.c
@@ -403,6 +403,23 @@ static void test_openprinter(void)
ok(res, returned %ld with %ld (expected '!=0')\n, res, GetLastError());
if(res) ClosePrinter(hprinter);
+/* a Space before the printername is invalid (bug 4268#c25) */
+if ((default_printer[0] != '\\')
+(lstrlenA(default_printer)-2 DEFAULT_PRINTER_SIZE)) {
+
+buffer[0] = ' ';
+lstrcpyA(buffer[1], default_printer);
+hprinter = (HANDLE) MAGIC_DEAD;
+SetLastError(MAGIC_DEAD);
+res = OpenPrinter(buffer, hprinter, NULL);
+ok(!res ((GetLastError() == ERROR_INVALID_PARAMETER) ||
+(GetLastError() == ERROR_INVALID_PRINTER_NAME) ),
+returned %ld with %ld (expected '0' with: \
+ERROR_INVALID_PARAMETER or ERROR_INVALID_PRINTER_NAME)\n,
+res, GetLastError());
+if(res) ClosePrinter(hprinter);
+}
+
defaults.pDatatype=NULL;
defaults.pDevMode=NULL;
defaults.DesiredAccess=0;
TaxAct 2005 file problem
As usual, this year's version of TaxAct has the same defect (or programming screw-up) it's had for years now that prevents it from being usable under Wine. The app installs fine, and will start to run as if it was sufficiently compatible with Wine. The problem with TA is that it *always* tries to first load a default data file (even if you give it a different filename as a command parameter), and the default filename is 2005 Tax Return File.ta5. It seems they are using a faulty or non-standard method of calling the default data file, as it will put up an error dialogue that it was unable to find it's default file, after which it exits. The specific message, captured by running a +msgbox debug switch is: == 1729146:0009:Call kernel32.lstrlenA(7e0a2ea0 Unable to open \2005 Tax Return File.ta5\.\n\nPlease verify that C:\\Apps\\TaxACT2005\\2005 Tax Return File.ta5 exists on your hard drive, if it does not you will need to reinstall TaxACT.) == I have a full WINEDEBUG=+relay,+msgbox capture of the programme run till failure exit, but it's 117M uncompressed (1.4M bz2 file). The app is also available as a free standard version (in fact, that's what I'm working with); the Deluxe version is merely an unlock code for the free download. https://www.taxact.com/s_taxact/free_taxact.asp?where=Registerproduct_id=0 5STDWad=0s=Ysc=05123 I had tried doing a WINEDLLOVERRIDE for shlwapi, ntdll kernel32 (various combinations) as these seemed to be the major dlls being loaded. But no success there. Please email me if you'd like more info from the debug file, or the file itself. Not being a developer, I don't frequent this list (just the wine-users list).
CVS build error on RH9
This patch: http://www.winehq.org/pipermail/wine-cvs/2006-January/020350.html doesn't compile on RH9. make[2]: Entering directory `/home/wine/wine/dlls/d3d8' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o device.o device.c device.c: In function `IDirect3DDevice8Impl_SetRenderState': device.c:3087: `GL_ARB_point_sprite' undeclared (first use in this function) device.c:3087: (Each undeclared identifier is reported only once device.c:3087: for each function it appears in.) device.c:3088: `GL_POINT_SPRITE_ARB' undeclared (first use in this function) make[2]: *** [device.o] Error 1 make[2]: Leaving directory `/home/wine/wine/dlls/d3d8'
Re: Benchmarks for 0.9.5
On Tue, 2006-01-17 at 17:22 -0500, Dimi Paun wrote: From: Tom Wickline [EMAIL PROTECTED] I was going to put the new results next to the old wine results, but I re-ran some of the test on XP as well because wine will run the HDD test in pcmark04 now. I can put up a page with 20050419 results vs 0.9.5 ?? That would be great, but please don't create another page. Just add one more column at the end (that would hold just the percentage difference of the old test), and put N/A for tests that were not run/available in 20050419. This seems like the best approach. Thank you very much for this Tom, it's rather interesting. Thanks, Scott Ritchie
Re: Benchmarks for 0.9.5
Tom Wickline twickline at gmail.com writes: On 1/17/06, Tom Wickline twickline at gmail.com wrote: Hello, Please take with a large dose of salt. http://wiki.winehq.org/BenchMark-0.9.5 Add more salt, I have the 3dmark2000 result browser installed and can get scores from full screen runs now. Just a suggestion, but it might be interesting to post the native Linux scores for those tests that have native Linux executables (i.e. ut2004, quake3). That should give us a theoretical best score, since it is unlikely that a Wine setup could surpass a native Linux binary (assume the options/features are identical of course). In the case of ut2004, it uses, by default, DirectX in windows and OpenGL in Linux I believe. As such a ut2004+opengl test might be a useful comparison as well. I haven't tried this myself though, so don't ask me how :) Regards, Aric
Re: HW address w/o connection in iphlpapi
Dang. It doesn't work for down devices. When I run strace on a program that uses getifaddrs, the socket is opened with IPROTO_IP: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 14 ioctl(14, 0x8912, 0x2084d3a8) = 0 That's SIOCGIFCONF. So it looks like getifaddrs isn't doing anything different than SIOCGIFCONF, at least on Linux. I can't figure out what these ioctls are either...? Take a look at linux/sockios.h I'll keep digging, but if you have any clues I would love to hear them! ifconfig -a reports down interfaces. It may just process /proc/net/dev. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
