Re: Add new nrelay debug channel - useful for debugging GPFs in target applications
Hi, On Wed, Mar 02, 2005 at 04:09:36PM +1100, Troy Rollo wrote: The nrelay (native relay) debug channel acts to limit the output of the relay debug channel, and only works if the relay debug channel is also on. When nrelay is on, relay will not log calls made from one built-in library to another built-in library, or within a built-in library. Thus each call logged is a call made directly by the target application or by one of the native DLLs it depends on. Yay!! Thanks a lot! This one is VERY important, since developer confusion by overwhelmingly big and mostly less useful relay logs in recent years has grown a lot, I'd say. One suggestion: maybe make *only* logging external relays the default, and add a wrelay channel to add back the logging of Wine inter-dll calls? This might make more sense even, since you're often not interested at all in Wine interactions, but what the target app does. Any suggestions about the average percentage where people are interested in app-only calls as opposed to a full relay log? That would then tell us which way to implement this limiting. I'm not sure about the percentage, since I haven't done much development in recent years. Andreas Mohr
Re: Help with winebuild/winegcc
[replying since it was the 2nd HELP! cry] Hi, On Tue, Mar 01, 2005 at 10:21:54PM +0100, Ivan Leo Puoti wrote: Hello, I'm trying to get a program in the programs/ directory to export symbols, I've added -shared path/to/spec/spec.c to the linker command, but I now get a segmentation fault at startup. Why not provide an strace/ltrace trace of that SEGV? Can someone knowledgeable about winegcc/winebuild give me a suggestion/solution? Definitely not me. ;-) I'm really stuck because of this and can't get on with safedisc support. Doh! Hopefully my suggestion will provide more clues. Andreas Mohr
Re: Add new nrelay debug channel - useful for debugging GPFs in target applications
Troy Rollo [EMAIL PROTECTED] writes: Activate by setting WINEDEBUG=relay,nrelay Alternatives considered but rejected: - Having a config file option. When the config file options are read it is already too late to prevent calls by and between kernel32.dll and ntdll.dll from being logged. This option clearly belongs with the similar ones in the config file, probably even as a special case of RelayFromExclude. The fact that it doesn't work properly on startup is not a reason to invent a new mechanism, the other config options don't work on startup either, and this needs to be fixed. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Add new nrelay debug channel - useful for debugging GPFs in target applications
Andreas == Andreas Mohr [EMAIL PROTECTED] writes: Andreas Hi, On Wed, Mar 02, 2005 at 04:09:36PM +1100, Troy Rollo wrote: The nrelay (native relay) debug channel acts to limit the output of the relay debug channel, and only works if the relay debug channel is also on. When nrelay is on, relay will not log calls made from one built-in library to another built-in library, or within a built-in library. Thus each call logged is a call made directly by the target application or by one of the native DLLs it depends on. Andreas Yay!! Thanks a lot! This one is VERY important, since Andreas developer confusion by overwhelmingly big and mostly less Andreas useful relay logs in recent years has grown a lot, I'd say. Andreas One suggestion: maybe make *only* logging external relays the Andreas default, and add a wrelay channel to add back the logging of Andreas Wine inter-dll calls? This might make more sense even, since Andreas you're often not interested at all in Wine interactions, but Andreas what the target app does. Andreas Any suggestions about the average percentage where people are Andreas interested in app-only calls as opposed to a full relay log? Andreas That would then tell us which way to implement this limiting. Andreas I'm not sure about the percentage, since I haven't done much Andreas development in recent years. I also suggest to make the behaviour described by Andi the default. Otherwise a very good feature. Thanks! -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: [winedbg] Get expressions working again.
I don't think this patch should go in as it is: - I don't think it's a good idea to have two ways to express a pointer type in the debugger (one being the standard dbghelp's SymTagPointerType, the other one the new deref count you've introduced). It would be better to add dynamic winedbg types (in the contrary to the static one's we already use dbg_itype_*), when we cannot find one in a module. - the returned string (for internal types' name) should be HeapAllocate:d, not a static buffer - please, use the current style for parenthesis, braces... and don't add a new oneA+ Message du 01/03/05 18:28 De : "Oliver Stieber" <[EMAIL PROTECTED]> A : [EMAIL PROTECTED] Copie à : Objet : [winedbg] Get expressions working again. Hi, This patch starts to get expressions working again and also allows derefrencing where there is no explicit type for that dereference. e.g. (short)0x12356 now returns the correct value instead of an error *((int *)0x23467) is now a valid _expression_. and ***((int ***)0x23467) should also work properly. This should also fix watches with expressions but I haven't given it much testing. Send instant messages to your online friends http://uk.messenger.yahoo.com [ winedbg_expressions_os_1.patch (18.4 Ko) ]
Re: gcov and Wine (was: Re: Wine cabinet.dll FDI Conformace Test Patch)
Dan Kegel [EMAIL PROTECTED] writes: You could provide a dummy implementation of __bb_init_func in the preloader, but that's uglier IMHO than just not passing those options when compiling the preloader. Sure, but you have to do that in a way that doesn't depend on configure, and doesn't require running sed magic on the command-line options. -- Alexandre Julliard [EMAIL PROTECTED]
Re: vartest.c - major pain in the build process
Dmitry Timoshkov wrote: In order to see what tests are affected by desktop visibility and which don't you have to run in both modes and compare the results. Why do it twice if it can be avoided? Right now any failure in the tests can be attributed to the desktop visibility, and until it's fixed nobody is going to fix the tests. You should email the guy who maintains winrash :-) Ivan.
Re: Help with winebuild/winegcc
Andreas Mohr wrote: Why not provide an strace/ltrace trace of that SEGV? ltrace fails with this $ltrace /usr/local/bin/wine ntoskrnl ltrace: dict.c:117: dict_apply_to_all: Assertion `d' failed. Aborted strace output is attached (It's bziped because it was over 200k uncompressed). I'm really stuck because of this and can't get on with safedisc support. Doh! Hopefully my suggestion will provide more clues. Well, I ran winegcc manually with the -v option, and found that normally programs build something with spec in the name anyway, so I changed the extension of my spec to .sspec and got the attached ntoskrnl.sspec.c file, unfortunately the build fails with make: Circular ntoskrnl.sspec.c - ntoskrnl.sspec dependency dropped. make: Nothing to be done for `all'. so without changing the makefile I renamed the file to .spec again and got this [EMAIL PROTECTED] ntoskrnl]$ make make: Circular ntoskrnl.sspec.c - ntoskrnl.sspec dependency dropped. gcc -g -O2ntoskrnl.sspec.c -o ntoskrnl.sspec /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/../../../crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' /home/ivan/tmp/ccZ0Wy9e.o(.text+0x10210): In function `__wine_dll_main': /home/ivan/Development/Wine/CVS/wine/build/programs/ntoskrnl/ntoskrnl.sspec.c:326: undefined reference to `__wine_main_environ' /home/ivan/tmp/ccZ0Wy9e.o(.text+0x10216):/home/ivan/Development/Wine/CVS/wine/build/programs/ntoskrnl/ntoskrnl.sspec.c:326: undefined reference to `__wine_main_argv' /home/ivan/tmp/ccZ0Wy9e.o(.text+0x1021c):/home/ivan/Development/Wine/CVS/wine/build/programs/ntoskrnl/ntoskrnl.sspec.c:326: undefined reference to `__wine_main_argc' /home/ivan/tmp/ccZ0Wy9e.o(.text+0x1025b): In function `__wine_spec_init': /home/ivan/Development/Wine/CVS/wine/build/programs/ntoskrnl/ntoskrnl.sspec.c:415: undefined reference to `__wine_dll_register' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x2c): In function `__wine_spec_exports_funcs': : undefined reference to `IoCreateDevice' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x30): In function `__wine_spec_exports_funcs': : undefined reference to `IoCreateSymbolicLink' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x34): In function `__wine_spec_exports_funcs': : undefined reference to `IoDeleteDevice' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x38): In function `__wine_spec_exports_funcs': : undefined reference to `IoDeleteSymbolicLink' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x3c): In function `__wine_spec_exports_funcs': : undefined reference to `IofCompleteRequest' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x40): In function `__wine_spec_exports_funcs': : undefined reference to `KeTickCount' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x44): In function `__wine_spec_exports_funcs': : undefined reference to `NtBuildNumber' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x48): In function `__wine_spec_exports_funcs': : undefined reference to `PsGetVersion' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x114): In function `__wine_spec_forwards': : undefined reference to `IoCreateDevice' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x124): In function `__wine_spec_forwards': : undefined reference to `IoCreateSymbolicLink' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x134): In function `__wine_spec_forwards': : undefined reference to `IoDeleteDevice' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x144): In function `__wine_spec_forwards': : undefined reference to `IoDeleteSymbolicLink' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x154): In function `__wine_spec_forwards': : undefined reference to `IofCompleteRequest' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x184): In function `__wine_spec_forwards': : undefined reference to `PsGetVersion' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x10d): In function `__wine_spec_forwards': : undefined reference to `IoCreateDevice' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x11d): In function `__wine_spec_forwards': : undefined reference to `IoCreateSymbolicLink' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x12d): In function `__wine_spec_forwards': : undefined reference to `IoDeleteDevice' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x13d): In function `__wine_spec_forwards': : undefined reference to `IoDeleteSymbolicLink' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x14d): In function `__wine_spec_forwards': : undefined reference to `IofCompleteRequest' /home/ivan/tmp/ccZ0Wy9e.o(.data+0x17d): In function `__wine_spec_forwards': : undefined reference to `PsGetVersion' collect2: ld returned 1 exit status make: *** [ntoskrnl.sspec] Error 1 [EMAIL PROTECTED] ntoskrnl]$ the program has a WinMain() and not a main(), all the exported functions are in the source, so I'm not sure about the reason for these errors. What I now think is that programs probably have some default spec that's built on the fly for them, and this is interfering with my spec. This is a real shame because ntoskrnl can actually run safedisc ATM, but it crashes when Secdrv.sys can't call the ntoskrnl functions it imports. The file I did build with a .spec file and that segfaults is at
Re: vartest.c - major pain in the build process
Ivan Leo Puoti [EMAIL PROTECTED] wrote: In order to see what tests are affected by desktop visibility and which don't you have to run in both modes and compare the results. Why do it twice if it can be avoided? Right now any failure in the tests can be attributed to the desktop visibility, and until it's fixed nobody is going to fix the tests. You should email the guy who maintains winrash :-) First of all that should be a collective request, not just a single voice in the dark. And I believe it should be a Wine test site maintainers responsibility (it's WineHQ web space after all), winrash has no direct relationship to Wine development since it's not in the Wine CVS. -- Dmitry.
Re: Ignore msi/version.res
Francois Gouget [EMAIL PROTECTED] writes: Francois Gouget [EMAIL PROTECTED] Ignore version.res. version.res is no longer generated. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Ptrace problem on amd64? (Was: Re: Warcraft III can't find cdrom)
T.J. Zeeman wrote:
Warcraft still complains about the CD-rom being MIA though :( I'll see
if I can dig up a few hints from the log this weekend.
Make sure your kernel hsa the ptrace regression fixes in.
I guess you meant the problems refered to in WWN250
(http://www.winehq.com/?issue=250). I checked and the patch there is
only for i386. I ported those to the x86_64 files (see attachments) and
tried again to no avail.
I also tried the test app as posted by Linus Torvalds here:
http://www.winehq.com/hypermail/wine-devel/2004/11/0551.html
When trying that on amd64 with the ptrace patches it does not even want
to compile (not completely surprising). In the chroot it segfaults.
A strace showed the following:
x5556c000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=32850, ...}) = 0
old_mmap(NULL, 32850, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5556d000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360Y\1...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1253924, ...}) = 0
old_mmap(NULL, 1260140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x55576000
old_mmap(0x5569f000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x129000) = 0x5569f000
old_mmap(0x556a7000, 10860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x556a7000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x556aa000
set_thread_area({entry_number:-1 - 11, base_addr:0x556aa2a0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0x5556d000, 32850) = 0
rt_sigaction(SIGTRAP, {0x8048438, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0
mprotect(0x8048000, 4096, PROT_READ|PROT_WRITE) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
I haven't been this deep into low level code in a long time (and that
was 8086 asm simulated on a sparc), but I thought this would work and
not segfault. Anybody around here that can comment on that? Or should I
take this to another forum to further investigate? If so, where would
you suggest I take it?
I'm not sure, probably lkml would be best but I'm not subscribed to
that. I'll CC wine-devel and maybe somebody there can help.
I'd recommend pinging Linus and asking about whether the ptrace
regressions still affect x86-64.
thanks -mike
regards,
Thomas
--- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/ptrace.c 2004-12-24 22:34:30.0 +0100
+++ ptrace.c 2005-03-01 20:32:29.713639136 +0100
@@ -79,6 +79,28 @@
return 0;
}
+static void set_singlestep(struct task_struct *child)
+{
+ long eflags;
+
+ set_tsk_thread_flag(child, TIF_SINGLESTEP);
+ eflags = get_stack_long(child, EFL_OFFSET);
+ put_stack_long(child, EFL_OFFSET, eflags | TRAP_FLAG);
+ child-ptrace |= PT_DTRACE;
+}
+
+static void clear_singlestep(struct task_struct *child)
+{
+ if (child-ptrace PT_DTRACE) {
+ long eflags;
+
+ clear_tsk_thread_flag(child, TIF_SINGLESTEP);
+ eflags = get_stack_long(child, EFL_OFFSET);
+ put_stack_long(child, EFL_OFFSET, eflags ~TRAP_FLAG);
+ child-ptrace = ~PT_DTRACE;
+ }
+}
+
/*
* Called by kernel/ptrace.c when detaching..
*
@@ -86,11 +108,12 @@
*/
void ptrace_disable(struct task_struct *child)
{
- long tmp;
+/* long tmp;
clear_tsk_thread_flag(child, TIF_SINGLESTEP);
tmp = get_stack_long(child, EFL_OFFSET) ~TRAP_FLAG;
- put_stack_long(child, EFL_OFFSET, tmp);
+ put_stack_long(child, EFL_OFFSET, tmp); */
+ clear_singlestep(child);
}
static int putreg(struct task_struct *child,
@@ -338,8 +361,6 @@
break;
case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
case PTRACE_CONT: { /* restart after signal. */
- long tmp;
-
ret = -EIO;
if ((unsigned long) data _NSIG)
break;
@@ -347,12 +368,9 @@
set_tsk_thread_flag(child,TIF_SYSCALL_TRACE);
else
clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE);
- clear_tsk_thread_flag(child, TIF_SINGLESTEP);
child-exit_code = data;
/* make sure the single step bit is not set. */
- tmp = get_stack_long(child, EFL_OFFSET);
- tmp = ~TRAP_FLAG;
- put_stack_long(child, EFL_OFFSET,tmp);
+ clear_singlestep(child);
wake_up_process(child);
ret = 0;
break;
@@ -394,34 +412,23 @@
* exit.
*/
case PTRACE_KILL: {
- long tmp;
-
ret = 0;
if (child-exit_state == EXIT_ZOMBIE) /* already dead */
break;
clear_tsk_thread_flag(child, TIF_SINGLESTEP);
child-exit_code = SIGKILL;
/* make sure the single step bit is not set. */
- tmp = get_stack_long(child, EFL_OFFSET)
Re: Add all MIME types
Scott Ritchie wrote: -MimeType=application/x-ms-dos-executable +MimeType=application/x-ms-dos-executable;application/x-msdos-program;application/x-msdownload;application/exe;application/x-exe;application/dos-exe;vms/exe;application/x-winexe;application/msdos-windows;application/x-msdos-program;application/x-zip-compressed NoDisplay=true Oh my god, there are a lot of these! Wouldn't it be a better long term solution to just get the desktop environments sorted out? They should be sharing the same MIME database now right? So why are they not all identifying EXEs as the same MIME type? thanks -mike
Visual C++ 6.0 as a Winelib IDE?
I have Visual C++ 6.0 running under Crossover Office 4.1, which of course means it's running under Wine. For one of the examples in the Wine/Winelib book, I decided to take the code produced by the VC++ Win32 Hello World wizard and see how to port it to Wine. Turns out, it's almost trivial. Create an empty directory, copy the *.c, *.rc, *.h, and *.ico files to it. VC++ produces tons of other files, but they're either used to maintain the Visual Studio environment, or are intermediate compilation files that aren't needed. Then run: $ winemaker . The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly. I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/Crossover Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed. All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it. Maybe after tweaking Winemaker and publishing a HOWTO we could show that this is a viable path? It's certainly easier than for Visual Studio developers and could help attract them to Wine. Another benefit - we could use the Visual C++ sample programs as tests for Wine. The programs might exercise areas that haven't been tested thoroughly. What do you think? Ira
Re: CVS SERVER OUT OF SPACE?
This was a CodeWeavers related function that is taking more disk space on our main server that we anticipated. All we did was clean up some space and warn folks within CodeWeavers that this can happen; that should suffice until we make the transition to the new set of servers that Jer has built up. The new servers are for CW; WineHQ gets to stay on the older server, but doesn't have to share it anymore. This is something Jeremy has been desparate to do fo years. His cheapskate boss has finally relented grin). We meet with the colo people tomorrow to plan the extra half rack we need and the switch will likely happen in the next few months. Cheers, Jer Andreas Mohr wrote: Hi, On Tue, Mar 01, 2005 at 03:00:50PM -0600, Jeremy Newman wrote: Sorry about that. All fixed now. The main question is: is it fixed or is it FIXED? There's a difference, ya know... FIXED meaning that this will occur never again due to an SNMP alert infrastructure (or something equally functional) being in place... (which I'd have assumed to be there already for WineHQ, given the relative importance of this server) Or maybe it simply was a temporary hickup/user error despite an alert infrastructure being in place already? (which thus must have been non-operational / ignored this time) Greetings, Andreas Mohr
Re: [winedbg] Get expressions working again.
--- Pouech Eric DMI AEI CAEN [EMAIL PROTECTED] wrote: I don't think this patch should go in as it is: - I don't think it's a good idea to have two ways to express a pointer type in the debugger (one being the standard dbghelp's SymTagPointerType, the other one the new deref count you've introduced). It would be better to add dynamic winedbg types (in the contrary to the static one's we already use dbg_itype_*), when we cannot find one in a module. Ok, I don't think I'll do this I don't have time to fix types_find_pointer and everywhere else to support module=0 properly. - the returned string (for internal types' name) should be HeapAllocate:d, not a static buffer - please, use the current style for parenthesis, braces... and don't add a new one Ok, I'll take a look at this, but if where shouldn't be using two pointer types we should be using SymGetTypeInfo in all cases? A+ Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: CVS SERVER OUT OF SPACE?
On Wed, 2005-03-02 at 09:18 +0100, Andreas Mohr wrote: FIXED meaning that this will occur never again due to an SNMP alert infrastructure (or something equally functional) being in place... (which I'd have assumed to be there already for WineHQ, given the relative importance of this server) Yes, I have server monitoring software in place. It warns me via email when the server breaks certain thresholds. I.e. disk space, process count, zombie count, user count, load average, etc. This happened because we had someone uploading us a linux distro DVD to our upload space on that server. I have remedied this problem by letting our users know to use one of our internal servers, not the web server to upload large files such as this. -- Jeremy Newman [EMAIL PROTECTED] CodeWeavers, Inc.
Re: Re: [winedbg] Get expressions working again.
Ok, I'll take a look at this, but if where shouldn't be using two pointer types we should be using SymGetTypeInfo in all cases? the only (two things) you have to do are: - if one cannot find the pointer type in the pointee's module, then create a winedbg's type for the pointer type and store this type in a lookup table - in type_get_info, extend the types supported by also searching the lookup table for the pointers type. the lookup table should containpointee type and module of pointee. You could also extend step 1 by not adding a pointer that already exists. A+
Re: CVS SERVER OUT OF SPACE?
Hi, On Wed, Mar 02, 2005 at 08:30:17AM -0600, Jeremy Newman wrote: On Wed, 2005-03-02 at 09:18 +0100, Andreas Mohr wrote: FIXED meaning that this will occur never again due to an SNMP alert infrastructure (or something equally functional) being in place... (which I'd have assumed to be there already for WineHQ, given the relative importance of this server) Yes, I have server monitoring software in place. It warns me via email when the server breaks certain thresholds. I.e. disk space, process count, zombie count, user count, load average, etc. Good guy :) This happened because we had someone uploading us a linux distro DVD to our upload space on that server. I have remedied this problem by letting our users know to use one of our internal servers, not the web server to upload large files such as this. The usual super-catastrophic events, it seems... (which probably could have been avoided here by having a separate partition or quota for the upload directory, but some critical things to be protected always tend to escape...) Andreas Mohr
Re: Visual C++ 6.0 as a Winelib IDE?
On Wed, Mar 02, 2005 at 05:22:24AM -0800, Ira Krakow wrote: The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly. Nice! I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/Crossover Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed. For MFC apps, I think you need to recompile MFC with Wine first. All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it. This can't be done, we don't have VC++ sources. And besides, you don't get any additional benefits as compared to just running the native PE. -- Dimi.
wine-user.pdf feedback
I think I have the answer why feedback to the wine-user.pdf has so far been disappointing: It's too well written. No questions to ask, almost. Actually, probably 90% of users try to get by without reading it. I saw a posting somwhere today, someone advising someone else about running the wine install, without mentioning uninstalling any old versions. The blind leading the blind. You need to put a big README!!!.TXT file somewhere, where it should say: You choose: Spend 1 day reading wine-user.pdf, and another day setting it up; or spend a week trying to set it up, a month asking questions at the forums, a year in depression, then finally a day reading wine-user.pdf, and another day setting it up. But probably, the lucky 10% who read it never have any questions, so you don't hear from them. In my case, though, combining a high IQ and being a complete helpless newbie to Linux, is a powerful combination that produces questions out of nowhere. In the chapter about installing and un-installing, one small detail got left out: How does one KNOW whether wine is installed, and if so what version it is? I'm sure it must sound like typical newbie crap questions to you, but to me it's a solid and tangible one. Well, I do know that I do have wine installed, because when I installed Fedora Core 2, I said install everything. Besides, I tried.. wine /mnt/C/windows/notepad.exe and it worked :-) :-) :-) But as for the version of wine I have, I have no idea how to find out. In Windows, I'd check the Add/remove programs, to see if it mentions the version, or I'd look in the installation folder for a readme.txt file. In Linux, not so easy: Even after doing a file search for wine, I still can't tell what folder it is installed in, if indeed it is installed in ONE folder, and not many. Looks like many, by the looks of it... Or at least two: One under /usr/local, which only contains two files, another for documentation, elsewhere, and I saw a folder somewhere with alotof.dll.so files. Anyways, thank you for the great work you've done and are doing. Some day Historians will remember you like today we remember Leonardo, or whoever: How Humanity rid itself of a great monopoli threat. As newbie as I am in Linux, I'm the expert here at work. If I can get our Windows apps to run on Linux, I might succeed at having the company switch over. Wish me luck.
wine-user.pdf feedback 2
Okay, now I found what I think is a more serious missing piece of info in wine-user.pdf. In page 20, last paragraph, it says one can start off by modifying the sample config file, which can be found in the directory 'documentation/samples'... Problem is, I did a file search for 'documentation', and I get like 10 pages of hits I did a file search for samples, and same thing, or worse. In both cases I went through all those instances visually scanning for 'wine' or 'config' and found nothing at all. I know I ought to have the sources somewhere, because when I installed fc2, I said install everything, and that included sources; but I have no idea where to look for the wine documentation folder. I have to give up on it for now. Far past my bedtime by now, anyways.. ;-) Cheers!
Re: Visual C++ 6.0 as a Winelib IDE?
Ira Krakow wrote: I have Visual C++ 6.0 running under Crossover Office 4.1, which of course means it's running under Wine. 1.5 years ago I had 3 problems with this. 1. It did not install. But that was not so bad because also on windows, VC6, if you copy an Installed directory and run it. Will work with some minor functionality missing. So it did load on wine. 2. When compiling, the std output was not redirected back to the IDE. 3. When debugging, it would Just do a Baaa and quit. Has any of these problems changed? Can you set a break point and run under the debugger? For one of the examples in the Wine/Winelib book, I decided to take the code produced by the VC++ Win32 Hello World wizard and see how to port it to Wine. Turns out, it's almost trivial. Create an empty directory, copy the *.c, *.rc, *.h, and *.ico files to it. VC++ produces tons of other files, but they're either used to maintain the Visual Studio environment, or are intermediate compilation files that aren't needed. Then run: $ winemaker . The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly. There are 2 easier ways that I know of to do this. 1. Use dev-c++ from www.bloodshed.net/devcpp.html. It will Just open your DSP file and make a very good, very simple MinGW makefile for you. It will add all your -D and -I and all this nightmare in big projects. Both the result makefile and dev-c++ itself can be used with wine. It has a native Linux port has well. One thing to try is debugging. It uses gdb for windows. Does gdb for windows runs under wine?? 2. Grab the DSW2MAKE util from MinGW. Written in Perl. The output makefile is very good for Winelib. Also keeps your -D(s), -I(s), and -l(s) and tries to convert other switchs as well. Better for very big projects. I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/Crossover Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed. MFC/ATL itself is not so simple... All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it. Maybe after tweaking Winemaker and publishing a HOWTO we could show that this is a viable path? It's certainly easier than for Visual Studio developers and could help attract them to Wine. If and when the VC++ Debugger can run under wine. (Even remotely) that will be the turning point for all the windows developers out there. Another benefit - we could use the Visual C++ sample programs as tests for Wine. The programs might exercise areas that haven't been tested thoroughly. Go grab CodeGuru.com CodeProjet.com . There is your exercise of Win32API. But from what I talked to Jeremy once, he said that from their experience, having the PE source code doesn't really change anything in the way you debug the app. All you need is the relay-trace anyway. So why not Just grab a real live App and have that run. What do you think? Ira Free Life Boaz
DPLAYX_ConstructData error during tools/wineinstall
Hi, I don't know when it started and if found I wasn't able to reproduce, but this is the message I sometimes get during a tools/wineinstall on a clean cvs install: Configuring Wine for a no-windows install in /data/wine-c... err:dplay:DPLAYX_ConstructData : unable to map static data into process memory space (487) /home/paul/.wine updated successfully. I can only say that I noticed this the last few (3?) weeks or so and haven't before. The first time I saw it, I did some regression testing, but as said, I wasn't able to reproduce at will. Is this a problem or can it be ignored (although it's an err). Or better yet, what could be the cause. Cheers, Paul.
%Fp printf format specifier
Hallo, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__heapwalk.asp uses a %Fp format spezifier. Running with native msvcrt, this seems to be the same as %p. However builtin msvcrt stumbles about the superfluous 'F. Does anybody know what the meaning of the F is? I didn't find anything on the net. And b.t.w., how do I get Google to not ignore the '%' in a search for %Fp? And mingw/malloc.h has the definitions of _USEDENTRY and _FREEENTRY excahnged and misses more entries... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: World of Warcraft - crash in game
On Fri, Feb 25, 2005 at 11:07:03AM +1100, Troy Rollo wrote: On Fri, 25 Feb 2005 09:22, Alex Woods wrote: Over the course of 13 (unlucky for me ;)) crashes, these are the only 3 addresses it has given. My question is what can I do to debug [target application SEGVs]. I can't find any good explanation of this either. Googling for gdb objdump site:winehq.org gets nothing relevant, and winedbg objdump is no better, so it may be that nobody has written an explanation for it before. Unfortunately, I never got to try out this method properly. WoW has it's own dbghelp.dll that it checks on login and that contains different functions to wine's dbghelp. So I got stuck there, but it's not all bad news. Whilst playing around trying to get some kind of lead, the sound cut out on me whilst playing the game. I decided to keep going, and the game played for a surprisingly long time. The next day I booted the game with wine's sound drivers disabled and played for about 10 hours total without a crash (for purely stress-test reasons you understand ;)). I've had a chance to give it a go with the wineoss.drv.so now and that also seems stable, so I guess the problem is in winealsa.drv.so which I had been using. I haven't had a chance to try to get some debug logs just for the sound yet, but when I get the time I will. Cheers. -- Alex
Re: wine-user.pdf feedback 2
Dan W. wrote: Okay, now I found what I think is a more serious missing piece of info in wine-user.pdf. In page 20, last paragraph, it says one can start off by modifying the sample config file, which can be found in the directory 'documentation/samples'... Hell Dan, The config file is in the source. http://cvs.winehq.org/cvsweb/wine/documentation/samples/ As for version $wine --version Tom
Re: Ptrace problem on amd64? (Was: Re: Warcraft III can't find cdrom)
On Wed, 02 Mar 2005 12:52:38 +, Mike Hearn [EMAIL PROTECTED] wrote:
I guess you meant the problems refered to in WWN250
(http://www.winehq.com/?issue=250). I checked and the patch there is
only for i386. I ported those to the x86_64 files (see attachments) and
tried again to no avail.
Anyway, the problem I had was that the cpu trap flag was being set
during kernel operations when it wasn't supposed to. The way I
finally discovered the exact spot was to make trap setting and
clearing verbose in logs under a working kernel and the broken kernel
and compare the logs. You need to make sure that 2.6.8 works and
2.6.9-rc1 or 2 breaks it, for this to be the same case. I know the
initial two patches did touch amd64, and the later fixes have not been
migrated to amd64.
I also tried the test app as posted by Linus Torvalds here:
http://www.winehq.com/hypermail/wine-devel/2004/11/0551.html
When trying that on amd64 with the ptrace patches it does not even want
to compile (not completely surprising). In the chroot it segfaults.
A strace showed the following:
x5556c000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=32850, ...}) = 0
old_mmap(NULL, 32850, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5556d000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360Y\1...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1253924, ...}) = 0
old_mmap(NULL, 1260140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x55576000
old_mmap(0x5569f000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x129000) = 0x5569f000
old_mmap(0x556a7000, 10860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x556a7000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x556aa000
set_thread_area({entry_number:-1 - 11, base_addr:0x556aa2a0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0x5556d000, 32850) = 0
rt_sigaction(SIGTRAP, {0x8048438, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0
mprotect(0x8048000, 4096, PROT_READ|PROT_WRITE) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
This is from the test program?
Jesse
Re: Dump HeapWalk entries
On Wed, Mar 02, 2005 at 05:52:45PM +0100, Uwe Bonnes wrote:
+ if ((entry-wFlags PROCESS_HEAP_ENTRY_BUSY )
+ (entry-wFlags PROCESS_HEAP_ENTRY_MOVEABLE))
+{
+ /* Treat as block */
+ DPRINTF( BLOCK-hMem\t\t:%08lx\n, (DWORD)entry-u.Block.hMem);
+}
Please don't introduce _another_ style of brackets, just use the
one that's used in the file. Should be either:
if () {
}
or
if ()
{
}
--
Dimi.
Re: wine-user.pdf feedback
On Wed, Mar 02, 2005 at 01:12:06AM -0500, Dan W. wrote: crap questions to you, but to me it's a solid and tangible one. Well, I do know that I do have wine installed, because when I installed Fedora Core 2, I said install everything. Besides, I tried.. wine /mnt/C/windows/notepad.exe and it worked :-) :-) :-) Do: which wine to figure out if it's installed. But as for the version of wine I have, I have no idea how to find out. wine --version installed in ONE folder, and not many. Looks like many, by the looks of it... Or at least two: One under /usr/local, which only contains two files, another for documentation, elsewhere, and I saw a folder somewhere with alotof.dll.so files. Under multiple folders, don't worry where it is. apps to run on Linux, I might succeed at having the company switch over. Wish me luck. Fingers and toes crossed! :) -- Dimi.
Re: Ptrace problem on amd64? (Was: Re: Warcraft III can't find cdrom)
On Wed, 2 Mar 2005 09:59:29 -0700, Jesse Allen [EMAIL PROTECTED] wrote: You need to make sure that 2.6.8 works and 2.6.9-rc1 or 2 breaks it, for this to be the same case. I know the initial two patches did touch amd64, and the later fixes have not been migrated to amd64. Here Andi Kleen expresses a dislike for an amd64 version of a patch that broke 2.6.9-rc1 on my x86 system: http://marc.theaimsgroup.com/?l=linux-kernelm=110379910702995w=2 The patch link: http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/|src/arch|src/arch/x86_64|src/arch/x86_64/kernel|related/arch/x86_64/kernel/entry.S Also here Andi speaks about the complexity of Linus' fixes and the problem of porting it to x86-64. http://marc.theaimsgroup.com/?l=linux-kernelm=110444869225886w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=110445367319392w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=110449669800844w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=110451344128991w=2 Entire thread: http://marc.theaimsgroup.com/?t=11005597081r=1w=2 My guess x86-64 hasn't been looked at since this last time. You need to make sure this is the same problem. Jesse
Re: World of Warcraft - crash in game
Hey, On Wed, 2 Mar 2005 16:43:11 +, Alex Woods [EMAIL PROTECTED] wrote: Whilst playing around trying to get some kind of lead, the sound cut out on me whilst playing the game. I decided to keep going, and the game played for a surprisingly long time. The next day I booted the game with wine's sound drivers disabled and played for about 10 hours total without a crash (for purely stress-test reasons you understand ;)). I've had a chance to give it a go with the wineoss.drv.so now and that also seems stable, so I guess the problem is in winealsa.drv.so which I had been using. I can confirm that. I only managed to get sound working to an acceptable rate (ticking, and stutters) with winealsa, no dmix/asym (I use that for my no harware mixing soundcard) and dsound hardware emulation. I will get a lot of these: fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=32768 primary_done=40572) err:dsound:DSOUND_MixOne underrun on sound buffer 0x404071d8 And: ALSA lib pcm_hw.c:590:(snd_pcm_hw_pause) SNDRV_PCM_IOCTL_PAUSE failed: Function not implemented err:wave:wodPlayer_ProcessMessages pcm_pause failed: Function not implemented This last error is probably because of my usb ALSA driver for my usb headset. Without dsound hardware emulation (so plain ALSA) I will get stuttering sound. And with wineoss (so, alsa oss emulation) I will not get any sound at all. This is with a 2.6.9 kernel and alsa-driver 1.0.8. Thanks, Paul
Re: Visual C++ 6.0 as a Winelib IDE?
Boaz, Has any of these problems changed? Can you set a break point and run under the debugger? You can set a break point, the debugger runs, and stops at the break point. You can inspect and change variables. However, Step Into, Step Over, doesn't work. If you try this after reaching the breakpoint, the debugging options are greyed out and the debugger ceases to function. So I guess it's some progress, but it's not totally there yet. There are 2 easier ways that I know of to do this. 1. Use dev-c++ from www.bloodshed.net/devcpp.html. It will Just open your DSP file and make a very good, very simple MinGW makefile for you. It will add all your -D and -I and all this nightmare in big projects. Both the result makefile and dev-c++ itself can be used with wine. It has a native Linux port has well. One thing to try is debugging. It uses gdb for windows. Does gdb for windows runs under wine?? I installed dev-c++ and really like it! The DSP import looks very promising - this is definitely an avenue I will pursue. I also like the Visual Studio-like look, and the fact that it creates makefiles for DLLs (static and dynamic), console apps, and Windows GUI apps. Haven't tried gdb for Windows under Wine. Also looks like a good idea. 2. Grab the DSW2MAKE util from MinGW. Written in Perl. These are all great suggestions. My next chapter will be to convert a real world app, which leans heavily on good debugging techniques. I want to define a good converstion path. You have helped me a lot. Thanks. Ira
Re: %Fp printf format specifier
Hi, On Wed, Mar 02, 2005 at 05:34:23PM +0100, Uwe Bonnes wrote: Hallo, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__heapwalk.asp uses a %Fp format spezifier. Running with native msvcrt, this seems to be the same as %p. However builtin msvcrt stumbles about the superfluous 'F. Does anybody know what the meaning of the F is? I didn't find anything on the net. And b.t.w., how do I get Google to not ignore the '%' in a search for %Fp? And mingw/malloc.h has the definitions of _USEDENTRY and _FREEENTRY excahnged and misses more entries... http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_format_specification_fields_.2d_.printf_and_wprintf_functions.asp doesn't tell *anything*. http://poli.cs.vsb.cz/c/help/alloc0.htm has a note the F modifier, which might hint that it is being used to indicate a far pointer... http://66.102.9.104/search?q=cache:_wVnYKwdJh0J:icon.dyu.ac.kr/clib/farheapwalk.pdf+printf+Fp+heapwalkhl=de strongly suggests the same... And http://poli.cs.vsb.cz/c/help/alloc0.htm as well, except that it even uses Fs! Do we even have to do anything on F? far is long gone, right? As such simply silently ignore F, right? Andreas Mohr
Re: %Fp printf format specifier
On Wed, 2 Mar 2005 19:24:33 +0100, Andreas Mohr
[EMAIL PROTECTED] wrote:
Do we even have to do anything on F?
far is long gone, right? As such simply silently ignore F, right?
Right now in current CVS, our *printf will handle any strings. For
any type numbers (except %n), they are forwarded to libc's printf by
first checking the format string for valid specifiers, and rebuilding
it for libc.
From line 585 in dlls/msvcrt/wcs.c:
else if( pf_is_valid_format( flags.Format ) )
{
char fmt[20], number[40], *x = number;
if( flags.FieldLength = sizeof number )
x = HeapAlloc( GetProcessHeap(), 0, flags.FieldLength+1 );
pf_rebuild_format_string( fmt, flags );
if( pf_is_double_format( flags.Format ) )
sprintf( number, fmt, va_arg(valist, double) );
Both pf_is_valid_format and pf_is_double_format will accept 'F'
(tolowerred...) modifiers, and libc will parse it. Based on windows
behavior, it probably should be ignored?
Jesse
Speach rec. on Wine
Hi, I am trying to get Dragon Naturally Speaking to run under Wine. I have got it installed successfully from CD, now I need to get it running. I have wine-20050111 installed , a 2.6.10 kernel and a current version of IE6 since Dragon apparently needs IE installed . Some advice please. Is there any fundemental problems which make this a no-hoper, has anyone got this working so far? Any a-priori conditions or advice I should know, like what sound model to use on Linux. Where should I search for detailed info on debugging something like this? There seems to be very little detailed help for Wine which I find surprising. Maybe I have just missed it Any other advice that could save me wasting lots of time. TIA .
Re: Visual C++ 6.0 as a Winelib IDE?
Ira Krakow wrote: You can set a break point, the debugger runs, and stops at the break point. You can inspect and change variables. This is amazing news. You should submit a little section about it for the Winelib hackers guide. And also for the user guides as it is an alternative to winedbg. One some people will like better. Eric, Mike 21 thumbs up :-} I get it from the lack of an answer that MSDEV installs the regular way, and that it is able to compile a project with output redirected into the IDE so you can double click on errors and stuff? However, Step Into, Step Over, doesn't work. If you try this after reaching the breakpoint, the debugging options are greyed out and the debugger ceases to function. So I guess it's some progress, but it's not totally there yet. Eric, Mike can you check this out? Does pe-gdb have the same problem with next/nexti? I installed dev-c++ and really like it! The DSP import looks very promising - this is definitely an avenue I will pursue. I also like the Visual Studio-like look, and the fact that it creates makefiles for DLLs (static and dynamic), console apps, and Windows GUI apps. Haven't tried gdb for Windows under Wine. Also looks like a good idea. Use it under dev-c++. Just make an hello word application put a break point and press debug. Please do this for me I must know ... 2. Grab the DSW2MAKE util from MinGW. Written in Perl. These are all great suggestions. My next chapter will be to convert a real world app, which leans heavily on good debugging techniques. I want to define a good converstion path. You have helped me a lot. Thanks. Ira
Re: %Fp printf format specifier
On Wed, 2 Mar 2005 11:51:57 -0700, Jesse Allen [EMAIL PROTECTED] wrote:
Right now in current CVS, our *printf will handle any strings. For
any type numbers (except %n), they are forwarded to libc's printf by
Oops, we handle %p differently too:
/* output a pointer */
else if( flags.Format == 'p' )
{
char pointer[10];
flags.PadZero = 0;
if( flags.Alternate )
sprintf(pointer, 0X%08lX, va_arg(valist, long));
else
sprintf(pointer, %08lX, va_arg(valist, long));
r = pf_output_format_A( out, pointer, -1, flags );
}
I don't think it will allow an 'F' to get stuck in an sprintf call.
If it did, then yeah, calling out libc's sprintf would mess it up. Do
we have a test case for %Fp? Uwe, what version of wine do you got? I
think only an older version would pass it on.
Re: %Fp printf format specifier
Jesse == Jesse Allen [EMAIL PROTECTED] writes:
Jesse On Wed, 2 Mar 2005 11:51:57 -0700, Jesse Allen
Jesse [EMAIL PROTECTED] wrote:
Right now in current CVS, our *printf will handle any strings. For
any type numbers (except %n), they are forwarded to libc's printf by
Jesse Oops, we handle %p differently too: /* output a pointer */ else
Jesse if( flags.Format == 'p' ) { char pointer[10];
Jesse flags.PadZero = 0; if( flags.Alternate )
Jesse sprintf(pointer, 0X%08lX, va_arg(valist, long)); else
Jesse sprintf(pointer, %08lX, va_arg(valist, long)); r =
Jesse pf_output_format_A( out, pointer, -1, flags ); }
Jesse I don't think it will allow an 'F' to get stuck in an sprintf
Jesse call. If it did, then yeah, calling out libc's sprintf would
Jesse mess it up. Do we have a test case for %Fp? Uwe, what version
Jesse of wine do you got? I think only an older version would pass it
Jesse on.
Most recent CVS...
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: %Fp printf format specifier
On Wed, 2 Mar 2005 20:24:27 +0100, Uwe Bonnes [EMAIL PROTECTED] wrote: Most recent CVS... Oh, since it hits 'F' first, it will try to parse it as 'f'. Maybe try this to see if it no longer accepts it as a valid specifer, and then maybe it will parse it as a pointer. --- wcs.c-original 2005-02-14 16:14:01.0 -0700 +++ wcs.c 2005-03-02 12:33:12.0 -0700 @@ -353,6 +353,8 @@ char float_fmts[] = acdefginoux; if (!fmt) return FALSE; +if (fmt == 'F') +return FALSE; fmt = tolower( fmt ); return strchr( float_fmts, fmt ) ? TRUE : FALSE; }
Re: %Fp printf format specifier
On Wed, 2 Mar 2005 12:35:47 -0700, Jesse Allen [EMAIL PROTECTED] wrote:
On Wed, 2 Mar 2005 20:24:27 +0100, Uwe Bonnes
[EMAIL PROTECTED] wrote:
Most recent CVS...
Oh, since it hits 'F' first, it will try to parse it as 'f'. Maybe
try this to see if it no longer accepts it as a valid specifer, and
then maybe it will parse it as a pointer.
This one is better because the other one will stop the parsing:
--- wcs.c-original 2005-02-14 16:14:01.0 -0700
+++ wcs.c 2005-03-02 12:51:05.0 -0700
@@ -555,6 +555,12 @@
*x = out-used;
}
+/* %F is silently ignored */
+else if( flags.Format == 'F' )
+{
+
+}
+
/* deal with integers and floats using libc's printf */
else if( pf_is_valid_format( flags.Format ) )
{
Re: %Fp printf format specifier
Dnia 02-03-2005, ro o godzinie 17:34 +0100, Uwe Bonnes napisa(a): uses a %Fp format spezifier. Running with native msvcrt, this seems to be the same as %p. However builtin msvcrt stumbles about the superfluous 'F. %p = pointer %Fp = far pointer? (as in segment:offset pointer in 16-bit Windows) Krzysztof
Re: World of Warcraft - crash in game
On Wed, Mar 02, 2005 at 06:52:36PM +0100, Paul van Schayck wrote: Hey, On Wed, 2 Mar 2005 16:43:11 +, Alex Woods [EMAIL PROTECTED] wrote: Whilst playing around trying to get some kind of lead, the sound cut out on me whilst playing the game. I decided to keep going, and the game played for a surprisingly long time. The next day I booted the game with wine's sound drivers disabled and played for about 10 hours total without a crash (for purely stress-test reasons you understand ;)). I've had a chance to give it a go with the wineoss.drv.so now and that also seems stable, so I guess the problem is in winealsa.drv.so which I had been using. I can confirm that. I only managed to get sound working to an acceptable rate (ticking, and stutters) with winealsa, no dmix/asym (I use that for my no harware mixing soundcard) and dsound hardware emulation. I will get a lot of these: fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=32768 primary_done=40572) err:dsound:DSOUND_MixOne underrun on sound buffer 0x404071d8 I get a lot of these too, with both winealsa and wineoss, but the rate seems very acceptable to me with not many ticks and stutters. I think also it got better in the last few days, and I notice that a few dsound changes were made, but I might be imagining things. I assume the dsound stuff is cpu bound. Without dsound hardware emulation (so plain ALSA) I will get stuttering sound. And with wineoss (so, alsa oss emulation) I will not get any sound at all. I just use whatever wine defaults to in that respect. I have a minimal config file: WINE REGISTRY Version 2 [version] windows=winxp [WinMM] Drivers=wineoss.drv [x11drv] DXGrab=Y Sound works about the same under both alsa and oss (again alsa oss emulation). It's strange that you get no sound from oss. The only visible difference between the drivers from a user level for me is that alsa makes the game unstable whereas oss does not. This is with a 2.6.9 kernel and alsa-driver 1.0.8. Similar here, alsa driver is whatever version 2.6.9 comes with, but the libraries are 1.0.7. -- Alex
user/tests/sysparams.c : test_SPI_SETKEYBOARDPREF on win98
Hi, I saw this test was recently added. It fails partly on my win98 box as this registry has the values in a different place. WinXP: [HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Preference] On=0 Win98: [HKEY_CURRENT_USER\Control Panel\Accessibility] Keyboard Preference=0 What's the best(tm) way to cater for both? Just use: SPI_SETKEYBOARDPREF_REGKEY and SPI_SETKEYBOARDPREF_WIN98_REGKEY for example and have the test check the windows version? Or change test_reg_key to cope with 2 different sets? Cheers, Paul.
Re: World of Warcraft - crash in game
On Thu, 3 Mar 2005 03:43, Alex Woods wrote: Unfortunately, I never got to try out this method properly. WoW has it's own dbghelp.dll that it checks on login and that contains different functions to wine's dbghelp. So I got stuck there, but it's not all bad news. In that case you may be able to use GDB directly on the executable (without winedbg) and attach after the app has started with gdb /usr/local/bin/wine-pthread process-id. The major drawback of this is that it cannot tell the difference between a first chance exception and a last chance exception, so if the app uses exception handling you may end up using GDB's pass command a lot.
Re: Use IsWindowVisible instead of GetWindowLong(GWL_STYLE) WS_VISIBLE as a test for desktop visibility
Dmitry Timoshkov [EMAIL PROTECTED] writes: let's see if IsWindowVisible() better detects a not visible desktop. Ah, fine, this may put some momentum into the situation! -- Feri.
Re: Use IsWindowVisible instead of GetWindowLong(GWL_STYLE) WS_VISIBLE as a test for desktop visibility
Ferenc Wagner wrote: Dmitry Timoshkov [EMAIL PROTECTED] writes: let's see if IsWindowVisible() better detects a not visible desktop. I would have thought the suggestions at this page would be better: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/interactive_services.asp Rob
Re: wine-user.pdf feedback
In my case, though, combining a high IQ and being a complete helpless newbie to Linux, is a powerful combination that produces questions out of nowhere. In the chapter about installing and un-installing, one small detail got left out: How does one KNOW whether wine is installed, and if so what version it is? I'm sure it must sound like typical newbie crap questions to you, but to me it's a solid and tangible one. Well, I do know that I do have wine installed, because when I installed Fedora Core 2, I said install everything. Besides, I tried.. wine /mnt/C/windows/notepad.exe and it worked *snip* You're definately right; some of the documentation needs to be updated, improved, or more generally geared towards complete newbies. In all fairness, a little over a year ago, I was a complete Linux newbie, and Wine was the first application I ever installed (compiled from source) and ran on Linux. :) Of course, it took some reading of the documentation, and some educated guessing, but it was possible. In any case, I don't know who currently maintains the documentation, but you sound like you have some great ideas to contribute to it. I encourage you to get involved. :) Hijinio __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
Dragon Naturally Speaking - working.
Good news and what looks like a first. Dragon Naturally Speaking 4 working under Wine. === reqd riched32 and comdlg32 native from 98SE Gentoo Linux , 2.6.10-nitro4 kernel wine-20050111 Fresh Wine installation installed IE6 using sidenet Install Dragon from CD no major issues. copy missing dll's ran up Dragon , enter user name , setup sticks at setting mike level but exits cleanly. #wine gentrain.exe picks up user name , dictated training text . It saves the vocab/voix profiles the drops out with 3 repeat errors but the profile is safe #wine natspeak.exe Can now dictate in stand-alone mode as in windoze. I now need some help with the guts of Wine to see if I can capture the keystrokes output by Dragon and pipe it to another Linux thread. Any suggestions on that? TIA :) -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: Visual C++ 6.0 as a Winelib IDE?
This is my first post in an attempt to help/clarify, so dont bash me too bad for format :) Boaz has been helping me offline quite a bit in the last few days. Thanks to Boaz, I have gotten about a half a million lines of code to compile, and Ive almost gotten them to link. It is looking VERY hopeful for my presentation on Monday, but I digress... At 12:01 PM 3/2/2005, Boaz Harrosh wrote: snip However, Step Into, Step Over, doesn't work. If you try this after reaching the breakpoint, the debugging options are greyed out and the debugger ceases to function. So I guess it's some progress, but it's not totally there yet. Are the buttons greyed out or does it misbehave when you click on the step into/over buttons? MSVC 6 running on Win2000 occasionally has the buttons greyed out when it lands on a breakpoint, but clicking on a source file ungreys them and then works fine. snip
Re: Dragon Naturally Speaking - working.
--- [EMAIL PROTECTED] wrote: Good news and what looks like a first. Dragon Naturally Speaking 4 working under Wine. === reqd riched32 and comdlg32 native from 98SE Gentoo Linux , 2.6.10-nitro4 kernel wine-20050111 Fresh Wine installation installed IE6 using sidenet Install Dragon from CD no major issues. copy missing dll's ran up Dragon , enter user name , setup sticks at setting mike level but exits cleanly. #wine gentrain.exe picks up user name , dictated training text . It saves the vocab/voix profiles the drops out with 3 repeat errors but the profile is safe #wine natspeak.exe Can now dictate in stand-alone mode as in windoze. I now need some help with the guts of Wine to see if I can capture the keystrokes output by Dragon and pipe it to another Linux thread. Any suggestions on that? Yes! :) Document what you did to get it working at the http://appdb.winehq.com web site so it can get recorded. :) Hiji __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
Re: Visual C++ 6.0 as a Winelib IDE?
On Wed, 02 Mar 2005 21:01:22 +0200, you wrote: I get it from the lack of an answer that MSDEV installs the regular way, and that it is able to compile a project with output redirected into the IDE so you can double click on errors and stuff? Yes you can, console windows pop-up where they should stay invisible is the remaining thing. There is a submitted, but not yes committed to cvs, patch that makes the scrollbars paint correctly. That includes the side bar with icons for breakpoint, markers and so. Look for Fix for scrollbar painting problem in Visual Studio in the patches list. Rein.
Re: [user/tests/sysparams.c] Added more SetLastError(0)'s
Paul Vriens [EMAIL PROTECTED] wrote:
as discussed a few times on wine-devel, there isa need to clear the
last error before calling a SPI_{GET|SET} routine.
It appears that not every call resets the last error to 0 on succession
and thus errors will propagate and leave us in the dark.
You have to set last error to some bogus value (usually 0xdeadbeef)
in order to test whether an API really has changed it.
--
Dmitry.
Re: %Fp printf format specifier
the net. And b.t.w., how do I get Google to not ignore the '%' in a search for %Fp? You're out of luck (presently). I also had this problem and asked them about it. Here's their answer: --- Thank you for your note. Google currently does not recognize search terms containing exclamation points, question marks, the @ sign, and other such characters. These characters are so common that including them in a search would greatly slow down results delivery and hurt search performance. Furthermore, the use of punctuation on the Web is so inconsistent (for example, there's no obvious way to decide between Mr. and Mr) that including it in the query often does more harm than good. That said, we know that many useful search terms do contain such characters. We've generated exceptions for terms like C++ and are studying ways to enable search terms like F# and C/net. We'll keep your feedback in mind as we work to improve the quality of our search. For more information, please visit http://www.google.com/help/refinesearch.html . Other helpful information can be found at http://groups.google.com in the http://groups.google.com/groups?hl=engroup=google.public.support.generalgroup. Please don't hesitate to contact us with any other questions or concerns. Thanks for your interest in Google. --- bye Fabi
