Re: [3/13] wineconsole and kernel32: set GetLargestConsoleWindowSize based on screen resolution
Le 08/04/2013 16:03, Nikolay Sivov a écrit : On Mon, Apr 8, 2013 at 4:47 PM, Hugh McMaster hugh.mcmas...@masterindexing.com mailto:hugh.mcmas...@masterindexing.com wrote: From: Nikolay Sivov [mailto:bungleh...@gmail.com mailto:bungleh...@gmail.com] Sent: Monday, 8 April 2013 11:08 PM To: wine-devel; Hugh McMaster Subject: Re: [3/13] wineconsole and kernel32: set GetLargestConsoleWindowSize based on screen resolution On Mon, Apr 8, 2013 at 3:53 PM, Hugh McMaster hugh.mcmas...@masterindexing.com mailto:hugh.mcmas...@masterindexing.com wrote: This file recreates most, if not all, of the source found in dlls/advapi32/registry.c in dlls/kernel32. It provides registry functionality. Why do you need this? If I remember correctly, there were several function dependencies for the registry implementation I worked on. I'm not sure of the exact number, but will work this out. What should I do then, though? Should I isolate the functions I need into a separate file? Or should the dlls/advapi32/registry.c be linked into the dlls/kernel32/Makefile.in? If you need to access registry from kernel32 you'll need to use ntdll calls directly. (not to mention that you can't just duplicate it like that) I'm not sure what you mean. The source remains correctly attributed as in the original. This functionality belongs to advapi32. Do you really need anything more than ntdll calls provide? and on top of that, using registry as a way to exchange information between wineconsole and kernel is not the right thing to do the correct way is to: - enhance the wine server protocol to grab max win size in kernel32 from wine server - enhance wineconsole to set the max wine size into wine server (and to recompute it when there's a screen resize event) A+
Re: Linker error when improving GetLargestConsoleWindowSize
This won't be able to work. The linker error is telling you, effectively, that you're not importing user32. However, kernel32 can't import user32. Kernel32 is at a lower level than user32. And a console program especially can't rely on user32 being loaded and initialized to satisfy the request you're making. Regards, Ken actually the correct fix would be to transfer this computation to wineconsole (which already imports user32), but thats' not a really trivial task A+
Re: A new demangler test?
Le 24/02/2013 07:07, Max TenEyck Woodbury a écrit : On 02/23/2013 02:54 AM, Eric Pouech wrote: Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : Would it be appropriate to add a test to the name demangler that: 1) Scans all '.dll' and '.spec' files for mangled names, and 2) Tries to decode those names. 3) Prints the mangled and decoded names and where they occur. Success would be that all names decode without the decoder blowing up or failing. adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+ One of the important aspects of name demangling is that it should work on _all_ the names in the current system. The current test does demangle a list of known strings, but that list was incomplete with respect to all the features used in real names the last time I dug into the details (which was none too recently). Scanning for all the real mangled names not only makes sure that the demangler is working properly, it also assures that all the names used are properly formed and decode to their intended values. I'm just saying that the test shouldn't embed the way to grab the mangled names it should be made outside of the test A+
Re: A new demangler test?
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : Would it be appropriate to add a test to the name demangler that: 1) Scans all '.dll' and '.spac' files for mangled names, and 2) Tries to decode those names. 3) Prints the mangled and decoded names and where they occur. Success would be that all names decode without the decoder blowing up or failing. adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+
Re: dbghelp: Implement rudimentary stack walk for ARM64
Le 21/01/2013 20:26, André Hentschel a écrit : Am 21.01.2013 10:50, schrieb Eric Pouech: +if ((frame-AddrPC.Mode == AddrModeFlat) +(frame-AddrFrame.Mode != AddrModeFlat)) this looks strange to me. I guess, you want to check that both mode address modes are AddrModeFlat A+ it's the same as for the other architectures do arm, thumb and arm64 have segmented addresses (or real mode addr) ? A+
Re: dbghelp: Implement rudimentary stack walk for ARM64
+if ((frame-AddrPC.Mode == AddrModeFlat) +(frame-AddrFrame.Mode != AddrModeFlat)) this looks strange to me. I guess, you want to check that both mode address modes are AddrModeFlat A+ -- Eric Pouech
Re: [PATCH 0/7] Series short description
Running make test with this series hangs in the hlink.c test, there seems to be a wineconsole process that never terminates. that's because rpcss is started from the hlink test, and is still a child of wineconsole (now) after the test terminated and wineconsole always waits for all its children to terminate before terminating rpcss should be created detached from current console I'll send a patch later on (and will also check that other services related program are correctly started) A+
Re: Help Splitting Patches
Le 30/12/2012 22:52, Adam Martinson a écrit : Looking for some help splitting patch 3, not sure how I can cut it down any more without breaking stuff. I'm guessing patch 9 will need splitting too, same problem. I haven't checked whether it's really possible, but one way to go would be to: - create a dedicated structure like server_end for the server end-point (instead of directly reusing the existing pipe_end) - then patch by patch move elements from pipe_instance to server_end + options + fd + ... - finally, when server_end and pipe_end have the same fields, just drop server_end for pipe_end HTH A+
Re: [PATCH 0/5] Moving bare consoles to wineconsole (try #2)
Try #2 (changes from previous patch) - fix changelog of first patch (was WineHelp...) - fix date in header for new file - remove setting title code (will be fixed in later patch) Actually the problem is not only the title. For instance it's still sending escape sequences when stdout is redirected. did you test that for the last patch in the patchset or for items in the middle of the patchset ? it's intended to work only for the last one in the patchset as it's easier to do it when the old code is removed, and not changing the old code to make it work in patch#2 and erase it in next patch A+ -- -- Eric Pouech
Re: [PATCH 0/5] Moving bare consoles to wineconsole (try #2)
hmm, that was intended to work (and did work for try#1, even though I didn't retest it in #2) :-( I'll look at it A+ 2012/12/19 Alexandre Julliard julli...@winehq.org Eric Pouech eric.pou...@orange.fr writes: Try #2 (changes from previous patch) - fix changelog of first patch (wastWineHelp...) - fix date in header for new file - remove setting title code (will be fixed in later patch) Actually the problem is not only the title. For instance it's still sending escape sequences when stdout is redirected. did you test that for the last patch in the patchset or for items in the middle of the patchset ? Yes, it happens with all the patches applied. -- Alexandre Julliard julli...@winehq.org -- -- Eric Pouech
Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
That doesn't look right. There's no guarantee that the handle is for the current process console. in fact, it's guaranted, because we check before (in the function calling this helper) that the handle is really a console handler and that it's in bare mode one could make it clearer by adding a comment to the helper function saying that those two conditions are met A+ -- Eric Pouech
Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
Le 20/11/2012 13:31, Alexandre Julliard a écrit : Eric Pouech eric.pou...@orange.fr writes: That doesn't look right. There's no guarantee that the handle is for the current process console. in fact, it's guaranted, because we check before (in the function calling this helper) that the handle is really a console handler and that it's in bare mode one could make it clearer by adding a comment to the helper function saying that those two conditions are met That doesn't guarantee that it's the process console, console handles can be passed across processes. yes, but the base console code is already broken wrt this point (we use the current process' console wait object instead of the wait object of the passed console) potential solutions ? - extending the server calls to support this behavior would break rights enforcement. not good IMO. - seperate the process to read input from fd(0) and the current running process (hence ensuring that we get the correct rights for writing) this is what we do with wineconsole (for other backends). moving bare console to wineconsole could also other benefits, as ensuring that the process controling the unix console doesn't die until the last wine process using it dies (and resetting the terminal control at exit) - any other ideas ? A+
Re: Any advice please... Console input issue
I tested the following HANDLE hConRW = CreateFileA(CONIN$ , GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); if (hConRW == INVALID_HANDLE_VALUE) hConRW = handle; ret = bare_console_fetch_input(hConRW, fd, timeout); if (hConRW!=handle) CloseHandle(hConRW); It works a charm, although feels inefficient for the times handle was already r/w - (it feels slightly odd that the 'handle' we are working on is unrelated to the handle passed in (I was worried about stdin redirection, but that seems to work fine even after the change). Was this what you meant or have I gone off on a tangent? more or less. I was thinking to add a helper functions for the writeconsoleinput calls in bare_console_fetch_input. and this helper function would : - try to call writeconsoleinput with the current console input handle - if it fails with status_access_denied, then create the right handle as you did - from your code, please use CreateFileW instead of CreateFileA A+ -- -- Eric Pouech
Re: Any advice please... Console input issue
Le 09/11/2012 22:49, Ann and Jason Edmeades a écrit : Hello, I've been looking at a patch which sorts out NUL and CON handling in a part of the command shell, and have stumbled upon a problem I am not sure how to fix because I really dont understand the underlying console handling, and would appreciate someone pointing me in a direction. For simplicity sake I've cut this down to a tiny test program, which works on windows and fails on wine which does the following: Opens the device (\\.\CON) with CreateFile with GENERIC_READ rights (which internally opens a CONIN$ device with the same access rights) Reads from the device with ReadFile - Because its a console device, this drops through to ReadConsoleW, which creates a CONOUT$ and then waits on a keystroke - Once the key is pressed (WCEL_Get) the key is 'inserted' into the input buffer by calling WriteConsoleInputW The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the CON device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try to open it with GENERIC_WRITE). CreateFile(CONIN$...) will let me open in GENERIC_READ/GENERIC_WRITE mode and the program works on both windows and wine, but if you open CONIN$ GENERIC_READ only then it fails on wine and works on windows, with the same issue. Now on windows, this works... the question is how to make it work on wine... My gut feeling, with nothing backing this at all, is that WCEL_Get should not use WriteConsoleInputW to inject the values into the input buffer, instead making the server call directly, but passing through to the server call something to indicate that it is ok to add the data to the buffer, but I'm fast getting out of my depth! Thanks for any help! I'll file a bug with my analysis and testcase, but would rather fix the thing! Jason from your (partial) explanation, I assume that : - you're using a bare console, ie didn't run your app under wineconsole, but simply as wine foo.exe - if so, does running your app under wineconsole provides the same bad effects ? - another item to test would be to see if writeconsoleinput really enforces the generic_write flag as msdn states but, for a bare handle, we have to convert unix console keystrokes into win32 keycodes, so we need to feed the keycodes into wine server if we really have to enforce generic_write, then we should wrap for TERM_ functions the calls to writeconsoleinput with a helper that reopens the console with the right mode A+
Re: [PATCH] wineboot: detect correct processor name and vendorID, use Intel Pentium 4 as fallback
Le 20/10/2012 12:42, Patrick Rudolph a écrit : This patch need lots of testing, since I can only test it on linux using an Intel CPU. Please tests on other OS and systems, too. please use the ntdll or kernel32 relevant API so that you don't have to copy the same code A+
Re: Have there been any problems with Wine on GCC 4.7?
-g was already the default. Most packagers (to my knowledge) provide a separate debug package, which isn't installed by default. i'm not especially speaking of packagers, but folks who compile wine themselves with something like: ./configure CFLAGS=-O2 and your patch forces -gdwarf2 (whatever -g is requested or not in CFLAGS) hence providing debug info when the user didn't ask for it A+
Re: Have there been any problems with Wine on GCC 4.7?
http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191eae3879fc422e2d -- -Austin the trouble with this patch is that it enables debug info whatever the default configuration is... A+ -- Eric Pouech
Re: [PATCH 3/3] [Msacm32]: in acmFormatChoose, added support for template
It would look much better without all those 'ret' + 'else' things. well, wine doesn't have coding guidelines... so I don't know what look much better means (project wise) A+ -- Eric Pouech
Re: Have there been any problems with Wine on GCC 4.7?
In the meantime, I suppose I could enable the -gdwarf-2 compiler option.
yes (but it's a bit more tricky than it sounds)
something like this will do
A+
diff --git a/configure.ac b/configure.ac
index 4bd43d1..2624dc1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -236,6 +236,12 @@ then
AC_SUBST(TARGETFLAGS,-b $host_alias $TARGETFLAGS)
fi
+dnl Check the debug format (force pure dwarf-2 debug format until we
correctly support other versions)
+tmp_cflags=$CFLAGS
+CFLAGS=`echo $CFLAGS | sed -e 's/-g\\/-gdwarf-2 -gstrict-dwarf/'`
+AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(int argc, char **argv) {
return 0; }]])],
+ [], [CFLAGS=$tmp_cflags])
+
dnl Check for flex
AC_CHECK_PROGS(FLEX,flex,none)
if test $FLEX = none
Re: [PATCH 3/3] [Msacm32]: in acmFormatChoose, added support for template
Le 13/08/2012 09:51, Dmitry Timoshkov a écrit : Eric Pouech eric.pou...@orange.fr wrote: It would look much better without all those 'ret' + 'else' things. well, wine doesn't have coding guidelines... so I don't know what look much better means (project wise) For this particalr patch it means: 1. less code 2. simpler code 3. more readable code and has nothing to do with coding guidelines for the whole project. P.S. I didn't even ask about the point in adding a bunch of spaces between 'MMRESULT' and 'ret' :) feel free to do it. I won't A+
Re: Have there been any problems with Wine on GCC 4.7?
diff --git a/configure.ac b/configure.ac index 4bd43d1..c80fd8a 100644 --- a/configure.ac +++ b/configure.ac @@ -1746,6 +1746,8 @@ then WINE_TRY_CFLAGS([-Wtype-limits]) WINE_TRY_CFLAGS([-Wunused-but-set-parameter]) WINE_TRY_CFLAGS([-Wwrite-strings]) + WINE_TRY_CFLAGS([-gdwarf-2]) + WINE_TRY_CFLAGS([-gstrict-dwarf]) dnl gcc-4.6+ omits frame pointers by default, breaking some copy protections case $host_cpu in would be simpler, unless I'm missing something. would work too (even if this would be preferable) + WINE_TRY_CFLAGS([-gdwarf-2 -gstrict-dwarf])
Re: Have there been any problems with Wine on GCC 4.7?
Le 24/07/2012 04:06, Scott Ritchie a écrit : Wine is the last remaining package still depending on GCC 4.5 in the current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port Wine, however 4.6 is known to not work too well. But now we have 4.7 -- have there been any bugs attributed to its usage? Thanks, Scott Ritchie afaik, gcc 4.7 enables by default dwarf4 as its default debug format, whilst wine (dbghelp) only supports dwarf2 it generates a lot of conbursome backtraces in winegdb I've started to add dwarf4 support to wine, but don't hold your breath (it's going to be hard and tedious afaict and will require quite a few changes to dbghelp for correctness) (and I have little time right now g) BTW : fedora 17 ships with gcc 4.7 A+
Re: Wine's support for reporting calling conventions
that's a limitation of dwarf format (IIRC, from the specs, you have either the default CC for your programming language/ABI, or a specific one without defining it further) FYII, the codeview format reports correctly this information note also that winedbg doesn't support calling functions in the debuggee, so this information is actually not used in winedbg A+ 2012/6/6, Roger Cruz roger_r_c...@yahoo.com: In dlls/dbghelp/dwarf.c, there is this snippet of code which appears to hard-code the calling convention to CALL_FAR_C. Does Wine not support reporting a function's calling convention correctly then? Is it a limitation of DWARF or just that it is not implemented? I can see that DWARF has a DW_AT_calling_convention field but when I examine a Wine DLL with objdump, it does not show this field in use. /* FIXME: assuming C source code */ sig_type = symt_new_function_signature(ctx-module, ret_type, CV_CALL_FAR_C); Thanks Roger -- -- Eric Pouech
Re: Error When Using winedbg on 64-bit Ubuntu 12.04
likely you're trying to debug a 32bit app using the 64bit debugger this doesn't work yet a+ 2012/7/21 John Edmonds john.a.edmo...@gmail.com I'm using 64-bit Ubuntu 12.04. I built and installed wine using the instructions from http://wiki.winehq.org/**WineOn64bithttp://wiki.winehq.org/WineOn64bit. Whenever I try to debug an application using winedbg I get the following error message: /var/chroot/usr/local/bin/**winedbg ~/.wine/drive_c/windows/** system32/notepad.exe err:module:LdrInitializeThunk Main exe initialization for LC:\\windows\\system32\\**notepad.exe failed, status c022 WineDbg starting on pid 0023 couldn't load main module (2) Process of pid=0023 has terminated This is the output when the same command is run with WINEDEBUG=warn+all: http://pastebin.com/RjErdbt8. My source tree is synced to git commit 020a68e1350eaf7293718732c1c920** 3e460709c6. Has anyone had success debugging Windows applications on 64-bit Linux? Thanks, John Edmonds -- -- Eric Pouech
Re: kernel32: Add a test for deleting an opened for reading file. Take 2.
one tricky question... could it be that on windows this test behaves
differently on ntfs vs FAT filesystem ?
or what would give re-opening the file after the deletefile call ?
A+
2012/6/21, Dmitry Timoshkov dmi...@baikal.ru:
Previous version had a typo in file name.
---
dlls/kernel32/tests/file.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/dlls/kernel32/tests/file.c b/dlls/kernel32/tests/file.c
index 8768b99..0a662d9 100644
--- a/dlls/kernel32/tests/file.c
+++ b/dlls/kernel32/tests/file.c
@@ -3236,6 +3236,31 @@ static void test_CreatFile(void)
DeleteFile(file_name);
}
+static void test_delete_file(void)
+{
+char temp_path[MAX_PATH], temp_file[MAX_PATH];
+HANDLE hfile;
+int ret;
+
+GetTempPathA(MAX_PATH, temp_path);
+GetTempFileName(temp_path, tst, 0, temp_file);
+
+SetLastError(0xdeadbeef);
+hfile = CreateFile(temp_file, GENERIC_READ, FILE_SHARE_DELETE |
FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0);
+ok(hfile != INVALID_HANDLE_VALUE, CreateFile error %d\n,
GetLastError());
+
+SetLastError(0xdeadbeef);
+ret = DeleteFile(temp_file);
+todo_wine
+ok(ret, DeleteFile error %d\n, GetLastError());
+
+SetLastError(0xdeadbeef);
+ret = CloseHandle(hfile);
+ok(ret, CloseHandle error %d\n, GetLastError());
+ret = DeleteFile(temp_file);
+todo_wine
+ok(!ret, DeleteFile should fail\n);
+}
START_TEST(file)
{
@@ -3257,6 +3282,7 @@ START_TEST(file)
test_CreateFileW();
test_DeleteFileA();
test_DeleteFileW();
+test_delete_file();
test_MoveFileA();
test_MoveFileW();
test_FindFirstFileA();
--
1.7.11
--
--
Eric Pouech
Re: msxml3: avoid a dangling else (LLVM/Clang)
while (*ptr) if (isspaceW(*ptr)) ptr++; else break; I do not mind terse code but that kinda overdoes it. I would put the else on a separate line. trafic on wine-devel is rather low those days what about opening a code-style flame-war ? A+ -- Eric Pouech
Re: Ubuntu 12.04 (version#2, drop previous mail)
This is the downside people in this thread are complaining about:
compiling 32-bit programs on a 64-bit Ubuntu install is now slightly
more difficult. However, Wine is currently the _only_ piece of
software I've encountered that needs to be built for both arches on
the same machine in order to be usable. We are beautiful special
snowflakes here: Wine developers who aren't using the build daemons is
about the extent of the current use case.
snip
I'm beginning to have memories of what happened when we removed gcc
from the default install. Setting up a 32-bit chroot for building
Wine should not be complicated -- I'll present a script to make it
even easier soon. You can build in a single command and even use
things like ccache and the like to speed it up.
to summarize:
ubuntu doesn't do anything to support developers
as it implies using ubuntu build daemons, not developers' machine
(and all the relevant environment)
as it implies to use chroot even on a multi lib arch = multi arch
is then for users, not developers
bye bye ubuntu then
for the sake of record (I won't even dare to send it to wine-patches) a
workaround ubuntu recvmsg breakage in order to get ptrace API to be
usable on 12.04
diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c
index 8a01d22..6c8e759 100644
--- a/dlls/ntdll/server.c
+++ b/dlls/ntdll/server.c
@@ -1016,6 +1016,37 @@ void server_init_process(void)
send_server_task_port();
#endif
#if defined(__linux__) defined(HAVE_PRCTL)
+/* work around Ubuntu's recvmsg breakage */
+if (!server_pid)
+{
+int zfd;
+struct flock fl;
+chartmp[4096];
+strcpy(tmp, wine_get_server_dir());
+strcat(tmp, /);
+strcat(tmp, LOCKNAME);
+
+if ((zfd = open( tmp, O_RDONLY )) == -1)
+fatal_error( no lock present %s.\n, tmp );
+
+fl.l_type = F_WRLCK;
+fl.l_whence = SEEK_SET;
+fl.l_start = 0;
+fl.l_len= 1;
+if (fcntl( zfd, F_GETLK, fl ) != -1)
+{
+if (fl.l_type == F_WRLCK)
+{
+/* the file is locked */
+fprintf(stderr, getting server_pid from lock %d\n,
fl.l_pid);
+server_pid = fl.l_pid;
+}
+fatal_error( cannot get pid from lock (lock isn't locked)\n);
+}
+else
+fatal_error( cannot get pid from lock\n);
+close(zfd);
+}
/* work around Ubuntu's ptrace breakage */
if (server_pid != -1) prctl( 0x59616d61 /* PR_SET_PTRACER */,
server_pid );
#endif
--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot. (Douglas Adams)
Re: Ubuntu 12.04 (version#2, drop previous mail)
This is because you _cannot_ install the 32-bit -dev packages onto 12.04. It's not just symlinks that are missing, many of the header files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least Just do the chroot. You will save yourself so much grief and it will actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+ -- -- Eric Pouech
Fwd: Ubuntu 12.04 (version#2, drop previous mail)
/Xlib.h:1695) [-Wdeprecated-declarations] this one can be forgotten for now (it's just being marked deprecated in precise, so warning doesn't come from misconfiguration) debugging (32bit and 64bit) is broken - the debugging is broken it turns out that ptrace and prctl (which had to be added in 11.10) work fine when tracing, only the first started process get correct pid out of wineserver in socket SCM_CREDENTIALS info. the later get 0 I tried to force the pid without requiring the recvmsg stuff and it works just fine I've not found yet the change that broke this more to come if get any futher on the remaining topics A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)
Le 29/04/2012 22:44, Eric Pouech a écrit : for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile This could be useful if you want to have a dual x86_64 : i386 setup this is an updated version to what I already sent to scott ritchie of course this is not a step by step installation I forgot to mention that ubuntu devels did a crappy job in 12.04 I'm really starting to get angry at their inability to take care of upward compat in what they do A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: winedbg and program stdout
Le 21/04/2012 10:33, Ilya Basin a écrit : When I debug a program with winedbg, it's output never goes to the same terminal. If it's compiled with -mconsole, it goes to a new console window; if compiled with -mwindows, the output is discarded. Any way to change this behavior? if your debuggee is a CUI (compiled with -m console), then winedbg forces to have two consoles, one for winedbg, the other one for the debuggee program that's a decision. if you want to change this, remove the CREATE_NEW_CONSOLE flag in programs/winedbg/tgt_active.c (actually we could make this an optional behavior of winedbg to share the current console with debuggee's output) if your debuggee is a GUI, it's windows default behavior not to create automatically a console for this program you need to call AllocConsole() in your debuggee for that. and it that case, wine will likely have to create a new window for the console A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: automate winedbg IDE integration
Le 14/04/2012 22:41, Ilya Basin a écrit : I've already written a wrapper (see my other mail winedbg-eclipse - winedbg wrapper for Eclipse IDE) There are some problems, however. EP do you have a trace of the gdb commands ? gdb --version gdb --interpreter mi2 --nx 1-list-features 2-environment-cd /media/ARCHLINUXOLD/1/builds/wine/src/wine/programs/regedit 3-gdb-set breakpoint pending on 4-gdb-set detach-on-fork on 5-enable-pretty-printing 6source .gdbinit 7-gdb-set target-async off 8-gdb-set auto-solib-add on 9-file-exec-and-symbols --thread-group i1 /media/ARCHLINUXOLD/1/builds/wine/src/wine/programs/regedit/regedit.exe.so 10-gdb-set --thread-group i1 args testexport 11-list-thread-groups --available 12-break-insert --thread-group i1 -f /media/ARCHLINUXOLD/1/builds/wine/src/wine/programs/regedit/regproc.c:1092 13-break-insert --thread-group i1 -f /media/ARCHLINUXOLD/1/builds/wine/src/wine/programs/regedit/regproc.c: 14-break-insert --thread-group i1 -t -f main 15-inferior-tty-set --thread-group i1 /dev/pts/0 16-exec-run --thread-group i1 IMO you're debugging a 64 bit target, and remote protocol seems to suffer some bugs in this case I'll send a fix later on... A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: automate winedbg IDE integration
Le 13/04/2012 22:21, Ilya Basin a écrit : which IDE do you have in mind ? Eclipse or Netbeans. Eclipse 3.7.2 looks promising. It even managed to detect -I and -D compiler options in the wine makefiles. I didn't work with Netbeans for long. The last time I had to manually set all the include directories and macros. some IDE provide sufficient parametrisation of gdb launching so that you can use directly winedbg --gdbnameofexe.exe Unfortunately, Eclipse passesnameofexe.exe not via command line, but as a GDB command. that's somehow also supported by winedbg (or supposed to be...) do you have a trace of the gdb commands ? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: automate winedbg IDE integration
Le 13/04/2012 19:58, Ilya Basin a écrit : Hi developers. There's a manual on this page: http://www.winehq.org/docs/winedev-guide/dbg-others Start the Wine debugger with a command line like: winedbg --gdb --no-startname_of_exe_to_debug.exe Start ddd In ddd, use the 'Open File' or 'Open Program' to point to the Wine executable (which is either wine-pthread or wine-kthread depending on your settings). In the output of 1/, there's a line like target remote localhost:32878 copy that line and paste into ddd command pane (the one with the (gdb) prompt) So many steps. Is there an easier way? Or maybe everyone use plain winedbg without any IDE? it depends on how the interaction with gdb is done... some IDE provide sufficient parametrisation of gdb launching so that you can use directly winedbg --gdb nameofexe.exe but YMMV which IDE do you have in mind ? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: winedbg: Respect Thumb mode when adjusting PC on ARM
Le 10/03/2012 18:26, André Hentschel a écrit :
---
programs/winedbg/be_arm.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/programs/winedbg/be_arm.c b/programs/winedbg/be_arm.c
index c39043c..6c1cc05 100644
--- a/programs/winedbg/be_arm.c
+++ b/programs/winedbg/be_arm.c
@@ -205,13 +205,15 @@ static void be_arm_clear_watchpoint(CONTEXT* ctx,
unsigned idx)
static int be_arm_adjust_pc_for_break(CONTEXT* ctx, BOOL way)
{
+INT step = (ctx-Cpsr 0x20) ? 2 : 4;
hmm
the way winedbg works might put us in trouble here...
when winedbg is entered with a break exception:
1/ winedbg calls adjust_pc_for_break(..., TRUE) to get the PC to the
real location of the break insn (and not after, as most CPU report in
break exception handler)
2/ user interacts with winedbg
3/ user resumes execution, and winedbg calls again
adjust_pc_for_break(..., FALSE)
but, the ctx passed here is the context used to resume execution... and
in ARM case Cpsr could have been changed by user in step 2/
leading to wrong PC computation in 3/
therefore, if we want to plug that hole, I'd suggest having two context
used in winedbg (the incoming one (never being changed), and the
current/outgoing one), and that we pass the two contexts in winedbg to
do the right thing here
A+
--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot. (Douglas Adams)
Re: winedbg: Respect Thumb mode when adjusting PC on ARM
Le 11/03/2012 09:18, Eric Pouech a écrit :
Le 10/03/2012 18:26, André Hentschel a écrit :
---
programs/winedbg/be_arm.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/programs/winedbg/be_arm.c b/programs/winedbg/be_arm.c
index c39043c..6c1cc05 100644
--- a/programs/winedbg/be_arm.c
+++ b/programs/winedbg/be_arm.c
@@ -205,13 +205,15 @@ static void be_arm_clear_watchpoint(CONTEXT*
ctx, unsigned idx)
static int be_arm_adjust_pc_for_break(CONTEXT* ctx, BOOL way)
{
+INT step = (ctx-Cpsr 0x20) ? 2 : 4;
hmm
the way winedbg works might put us in trouble here...
when winedbg is entered with a break exception:
1/ winedbg calls adjust_pc_for_break(..., TRUE) to get the PC to the
real location of the break insn (and not after, as most CPU report in
break exception handler)
2/ user interacts with winedbg
3/ user resumes execution, and winedbg calls again
adjust_pc_for_break(..., FALSE)
but, the ctx passed here is the context used to resume execution...
and in ARM case Cpsr could have been changed by user in step 2/
leading to wrong PC computation in 3/
therefore, if we want to plug that hole, I'd suggest having two
context used in winedbg (the incoming one (never being changed), and
the current/outgoing one), and that we pass the two contexts in
winedbg to do the right thing here
A+
and I forgot my question... is it possible for the user to change the
cpsr value?
A+
--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot. (Douglas Adams)
Re: wineconsole: Remove the character-width check as we need newer FreeType library.
Le 15/12/2011 17:18, Akihiro Sagawa a écrit : On Wed, 14 Dec 2011 19:35:34 +0100, Eric Pouech wrote: this doesn't solve the printing issue as the always infer that any char has the same size how is this printed on real windows with your character set ? See the attachment, please. It was taken in my Windows 7 PC with Japanese Terminal font. Most of Japanese characters take up the double width of the ASCII characters. For example, the first Japanese character (KATAKANA LETTER DO, U+30C9) is as same width as `:¥' (=two halfwidth characters). Unicode Standard Annex #11, East Asian Width (*), may help understanding East Asian character width. * ... http://www.unicode.org/reports/tr11/ In the document, some characters are defined as ambiguous. And its recommendation is that ambiguous characters always map to fullwidth characters when mapping Unicode to East Asian legacy characters. But actually it depends on locales or encodings. For instance, as shown in the bottom echo line in the snapshot, U+E1 (LATIN SMALL LETTER A WITH ACUTE) is halfwidth and U+B1 (PLUS-MINUS SIGN) is fullwidth in Japanese environment. In my humble opinion, printing issue is not good especially for users. But, as far as I know, it doesn't occur in ASCII characters. And it is better than showing the error message, Couldn't find a decent font, aborting, at starting up. as pointed out in http://blogs.msdn.com/b/buckh/archive/2005/09/11/463427.aspx#2250089 those Japanese characters need to be stored in two adjacent cells in the console infrastructure code... your patch will actually print them on top of two cells, while it's going to be stored only in one... it would then lead to making all the output (and internal encoding) be wrong A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: wineconsole: Remove the character-width check as we need newer FreeType library.
this doesn't solve the printing issue as the always infer that any char has the same size how is this printed on real windows with your character set ? A+ 2011/12/14 Akihiro Sagawa sagawa@gmail.com This closes bug #10063. This check is needed for FreeType 2.0.8, but commit 570e68b82200bdd9981b2cd8fe9e68d35bad3cb9 updated the requirement, 2.1.4 or later. And it is not useful for DBCS fonts, as they have two different width (halfwidth and fullwidth) even in monospaced font such as MS Gothic. --- programs/wineconsole/user.c | 34 ++ 1 files changed, 2 insertions(+), 32 deletions(-) -- -- Eric Pouech
Re: [PATCH] server: assert on failure to open /dev/null (Coverity)
Marcus, IMO,fatal_error() should be preferred over assert() (hoping that fatal_error() is actually marked as no_return) A+ 2011/11/25 Marcus Meissner meiss...@suse.de Hi, if we cannot open /dev/null something is really broken. CID 5470 Ciao, Marcus --- server/request.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/server/request.c b/server/request.c index 05c7464..06fdbe8 100644 --- a/server/request.c +++ b/server/request.c @@ -760,6 +760,7 @@ void open_master_socket(void) /* make sure the stdio fds are open */ fd = open( /dev/null, O_RDWR ); +assert (fd != -1); while (fd = 0 fd = 2) fd = dup( fd ); if (!server_dir) fatal_error( directory %s cannot be accessed\n, config_dir ); -- 1.7.1 -- -- Eric Pouech
Re: [PATCH 3/6] [UnInstall]: No longer use unix stdio functions, but the kernel32 equivalent
Le 07/11/2011 14:12, Alexandre Julliard a écrit : Eric Pouecheric.pou...@orange.fr writes: #28185 A+ --- programs/uninstaller/main.c | 65 ++- 1 files changed, 46 insertions(+), 19 deletions(-) I'm not sure that's a good idea. The output of uninstaller is meant to be used by Unix apps, it's not something a user would want to display on the console. do you consider it's the same for winepath and winetest (number 5 6 in patchset) ? or shall I resubmit the remaining two ? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: cmd: Avoid mixing signed and unsigned type in conditional expression
why do we check for ptr being null or not, when we deref ptr one line above
?
something's wrong in the code logic
A+
Le 27 octobre 2011 04:53, Frédéric Delanoy frederic.dela...@gmail.com a
écrit :
---
programs/cmd/wcmdmain.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/programs/cmd/wcmdmain.c b/programs/cmd/wcmdmain.c
index 56aa85f..1bcc598 100644
--- a/programs/cmd/wcmdmain.c
+++ b/programs/cmd/wcmdmain.c
@@ -278,7 +278,7 @@ static void WCMD_output_asis_handle (DWORD std_handle,
const WCHAR *message) {
ptr++;
};
if (*ptr == '\n') ptr++;
- WCMD_output_asis_len(message, (ptr) ? ptr - message :
strlenW(message), handle);
+ WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) :
strlenW(message), handle);
if (ptr) {
numChars = 0;
if (++line_count = max_height - 1) {
--
1.7.7.1
--
--
Eric Pouech
Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile
Le 4 octobre 2011 13:40, Frédéric Delanoy frederic.dela...@gmail.com a
écrit :
2011/10/4 Dan Kegel d...@kegel.com:
+ * handle_type: type of hIn handle
+ * 0 if file, 1 if console, anything else if unknown
(autodetect)
I suspect you want an enum for that.
Well I thought about that, but found it a bit overkill for such a
limited set of possible values.
Also, if I used sthg like
enum CMD_HANDLE_TYPE {
CMD_HT_FILE = 0,
CMD_HT_CONSOLE = 1,
CMD_HT_UNKNOWN = 2
}
again, this is not needed (passing all thoses CMD_HT bits)
static inline BOOL is_console_handle(HANDLE h) {return ((DWORD_PTR)h) 3 ==
3;}
will test every handle and tell whether it's a console or a regular (file,
pipe...) handle
A+
--
--
Eric Pouech
Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile
I don't quite understand what you mean. WCMD_ReadFile is called directly/indirectly in a lot of places, mostly around line-by-line reads. The question is not whether the compiler will inline this function (you can't know that for sure, think -O0, different compilers, etc.), but whether you want to check that every time. This function is_console_handle() could be inlined or not/fast, but that's not the point. The point is why would one want to run that function when not necessary, i.e. when callers already know the type. It's just about finding/detecting the handle type once and only once (per handle). the point is about passing twice the information to a given function the point is about adding unnecessary enums that clutter all the code the point is about thinking that you're only computing once a value, while you still need to compare the handle type (as you added it) to a given number A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [2/3] cmd: Avoid checking whether we're in console mode for every read (try 2)
Le 28/09/2011 01:01, Frédéric Delanoy a écrit : --- programs/cmd/batch.c|9 - programs/cmd/builtins.c |4 ++-- programs/cmd/wcmd.h |5 +++-- programs/cmd/wcmdmain.c | 21 + 4 files changed, 22 insertions(+), 17 deletions(-) actually, console handles have their 2 lower bit set you could use it to even simplify further the code A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Auto-selecting local variable/parameters when 'p'rinting values using winedbg?
Le 12/09/2011 10:32, Frédéric Delanoy a écrit : 2011/9/12 Frédéric Delanoyfrederic.dela...@gmail.com: I found that --file accepts the set of commands to execute (but winedbg exits afterwards), but what does --command do? OK --command simply executes a single command and exits/continues the program until termination. Is there a way to specify initial commands to execute, then stay *inside* winedbg after the last command of the file is issued? not currently Or maybe I should use stuff like 'expect' to do that? IMO, the best solution would be to: - let winedbg have a default init command file (say .winedbgrc) to be loaded at startup (if the file exists in current directory, then in ~ directory...) - add to generic options to winedbg: + the first one to give an alternate name to default .winedbgrc file (or to locate it) + the second one to tell winedbg not to load the default file regarding the 'expect' stuff, you can look at the automaton to test winedbg https://github.com/ericZp/wdtp not sure it fully matches what you want to do, but it can help A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Auto-selecting local variable/parameters when 'p'rinting values using winedbg?
Le 09/09/2011 13:02, Frédéric Delanoy a écrit : 2011/9/9 Eric Pouecheric.pou...@orange.fr: WineDbg set ! symbol_picker scoped will do what you want unfortunately, there's no way to store it as a default command (you can always use --command or --file on command line to help) Thanks for that quick response! Is there some doc on the internal commands, besides the code? http://www.winehq.org/docs/winedev-guide/dbg-config may be a bit out of date Frédéric not for that part... feel free to bring to the doc up to date set ! symbol_picker interactive being the other setting (which is the default : if several symbols found, ask the user for which one to pick) scoped meaning give precedence to local symbols over global symbols A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH] cmd: Avoid rereading batch file for every call/goto executed (try 3)
this won't work if a .bat file calls another .bat file the cache must be stored inside the context structure... A+ -- Eric Pouech
Re: kernel32: Fix writing to a pipe in WriteConsoleW().
Le 01/09/2011 16:22, Francois Gouget a écrit : On Wed, 24 Aug 2011, Eric Pouech wrote: [...] you can safely provide the patches with protecting WriteConsole and friends with a if (!is_console_handle(???)) return FALSE; line Would something like the attached patch be ok? As far as I can see all the other APIs pretty much immediately pass the handle to wineserver which I expect will complain if it's not a console handle. Further notes: * Performing the 'console handle check' locally would likely be faster but, except for WriteConsole maybe, this should usually be the case and is probably not performance critical anyway. * There are a few cases where we check for invalid parameters and return an error before the handle is checked by wineserver. It's possible that in such cases Windows checks the handle first. But unless we know of applications that need the right error code in these corner cases it does not justify adding an explicit check. actually, a couple of API support the bare handles and those should be protected (what your patch does) otherwise, wineserver iwill fail on them this patch looks ok, but you have to reverse the previous one as well A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Where is the best place to report a fscanf bug found under wine-1.3.27?
Le 30/08/2011 20:38, Peter Rosin a écrit : Den 2011-08-30 20:18 skrev David Laight: On Mon, Aug 29, 2011 at 06:43:41PM -0700, Alan W. Irwin wrote: double x; while(fscanf(stdin, %le ,x) == 1) You are using the wrong format, %le is for 'long double', this will probably overwrite too much data. Nope, you are mistaken and the OP is correct. %e float %le double %Le long double Cheers, Peter from what I understand, double and long double have the same precision under msvc, while they don't on linux (and gcc) likely a problematic conversion somewhere in the code path A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: kernel32: Fix writing to a pipe in WriteConsoleW().
so it would make more sense to simply let WriteConsoleW fail when is_console_handle(hConsoleOutput) is FALSE ? (similar functions as WriteConsoleA, ReadConsoleA/W should be protected the same way) Currently only three APIs in console.c check is_console_handle(): VerifyConsoleIoHandle(), DuplicateConsoleHandle() and CloseConsoleHandle(). That could certainly be extended to others and things even seems to work if I add a simple 'if (!is_console_handle(hConsoleOutput)) return FALSE;' at the start of WriteConsoleW(). then that's the correct way to fix it One could then rip out the code in the WriteFile() branch but I'm not sure what the consequences of all this would be or why the WriteFile() case was added in the first place. The author of that code would probably know better than meg. no, the WriteFile stuff must be kept basically, we need to handle three cases (h being the handle passed to WriteConsole) C1/ h isn't a console handle (ie lower bits not set) = fail (return FALSE) C2/ h is a console handle, and removing the lower bits we have a handle to a console object in wine server = call wineserver C3/ h is a console handle, and removing the lower bits we have a handle to a file object in wine server = call WriteFile = ... you get : - C1 when output is redirected to a file/pipe... - C2 when running wineconsole net.exe - C3 when running wine net.exe note that we're playing with handles, and hidding behind console handles (with lower bit sets) handles to other objects... (in fact, from your first post, there is no infinite loop as the calls are made on different objects) you can safely provide the patches with protecting WriteConsole and friends with a if (!is_console_handle(???)) return FALSE; line A+ -- Eric Pouech
Re: kernel32: Fix writing to a pipe in WriteConsoleW().
Le 03/08/2011 18:07, Francois Gouget a écrit : WriteFile() checks if the handle corresponds to the console and if it does invokes WriteConsoleA(). This barely escaped an infinite loop but messed up the string encoding as CP_UNIXCP is usually different from CP_ACP. --- I noticed this issue while testing the net.exe tool. After making it use WineConsole() I was getting the following outputs: $ wine net stop Spécifie le service à arrêter. $ ./wine net stop | cat Sp├®cifie le service ├á arr├¬ter. It turns out that it's because we only get through the WineConsoleW() - WriteFile() - WriteConsoleA() loop in the second case. could you elaborate a bit more. in case of wine ... | cat, the standard output should be a pipe not a console so writeconsoleW is supposed to fail so it would make more sense to simply let WriteConsoleW fail when is_console_handle(hConsoleOutput) is FALSE ? (similar functions as WriteConsoleA, ReadConsoleA/W should be protected the same way) A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Winhelp crash in assertion(0) if .hlp file is not found
I've just sent a patch that should fix it. A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Winhelp crash in assertion(0) if .hlp file is not found
your proposal isn't fixing the problem, it just hides it what seems (to be confirmed) to happen is that winhelp should better support secondary windows as 'glossary' (or have fallback for those) as it does for primary window (called 'main') (or support defining window name when opening a file) can you send me (in private) the relevant .hlp files (main one and glossary.hlp) I'll have a deeper look -- Eric Pouech
Re: no line numbers in backtraces on Mac OS X?
we miss dwarf support on mac it's likely the cause here (if you can, you can try to compile with stabs, it should work) (there's an open bug in bugzilla for this) A+ 2011/5/23 joerg-cyril.hoe...@t-systems.com Hi, Is it normal that there are no source line numbers in backtraces on Mac OS? Despite many patches to winedbg etc., the backtraces I get are no better that those from 1.1.24 times. 18 0x41f5b2a1 _OpenDriverA+0x51() in winmm (0x0032ce78) 19 0x4041467f _initAudioDlg+0x75f() in winecfg (0x0032dc28) I'm using configure + make to build. On Linux, the line numbers help a lot in locating bogus code. Thank for your help, Jörg Höhle. -- -- Eric Pouech
Re: dbghelp: Implement SymEnumSourceFilesW.
The A version should call the W one, not the other way around. Alexandre, in order to properly manage this, we need to move file names in dbghelp from ansi to unicode but, as dbghelp API uses some kind of regular expression to match filenames, we need a unicode regex function set unfortunately, glib doesn't provide this (yet) so, shall we ?: - embed a (simple) unicode regex lib in dbghelp - or make generic in libwine (so that the day that glib provides the right interface we can use it) - or ... libTRE seems a good choice here, with compatible license A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: tests/msvcrt: add test for _splitpath function
adding c:test.txt (and friends) as input should be also interesting
UNC paths should also be tested
A+
+} Paths[] = { {C:/directory/test.txt, C:, /directory/,
test, .txt},
+{C:\\directory\\test.txt, C:, \\directory\\,
test, .txt},
+{C:\\directory\\test, C:, \\directory\\, test,
},
+{C:\\directory\\.txt, C:, \\directory\\, ,
.txt},
+{C:\\directory\\, C:, \\directory\\, , },
+{C:\\test.txt, C:, \\, test, .txt},
+{C:\\test, C:, \\, test, },
+{C:\\.txt, C:, \\, , .txt},
+{C:\\, C:, \\, , },
+{\\directory\\test.txt, , \\directory\\, test,
.txt},
+{\\directory\\test, , \\directory\\, test, },
+{\\directory\\.txt, , \\directory\\, , .txt},
+{\\directory\\, , \\directory\\, , },
+{\\test.txt, , \\, test, .txt},
+{\\test, , \\, test, },
+{\\.txt, , \\, , .txt},
+{\\, , \\, , },
+{test.txt, , , test, .txt},
+{test, , , test, },
+{.txt, , , , .txt},
+{, , , , }};
--
Eric Pouech
Re: msvcrt: Don't pass NULL as __ms_va_list in printf implementation
You could va_copy() it to a second va_list if you need to do it twice. va_copy is C99. Are we ready to say that is now dependant to C89 ?. A+ -- Eric Pouech
Re: gecko and native msvcrt
Le 30/04/2011 12:15, Jacek Caban a écrit : On 4/29/11 11:58 PM, Eric Pouech wrote: Le 29/04/2011 23:07, Dan Kegel a écrit : While testing a game with current gecko, I saw the error wine: Call from 0x7bc4ad90 to unimplemented function msvcrt.dll._snwprintf_s, aborting The game needed a native msvcrt, so I had installed one with winetricks, and it didn't export that function. So it seems that new gecko is incompatible with old msvcrt, and using native msvcrt as a workaround for bugs in wine's version is going to be harder than it used to be. Time to fix more of them msvcrt bugs, I guess... And/or find a more up to date msvcrt.dll for winetricks. or link gecko against msvcr80 or msvcr90 instead of msvcrt It's harder than it seems, esp. because it's not well supported by mingw-w64. Also even if we did it, Wine would still forward these calls to msvcrt, so one would need another native DLL. Given that, we need more serious reason for the change than supporting hackish winetricks verb. Fixing our msvcrt implementation is the way to go IMO. I don't agree on your last point in native msvcrt, there is none _snwprintf_s function (it only exists in msvcrN where N=8 (didn't really check all versions)) _snwprintf_s is implemented in our msvcrN (which forwards them to msvcrt) the point here is that one tries to run gecko with native msvcrt which doesn't contain this function so if gecko needs it, it shouldn't link to msvcrt but to msvcrN is we want to maintain compat with native DLLs A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: gecko and native msvcrt
Le 29/04/2011 23:07, Dan Kegel a écrit : While testing a game with current gecko, I saw the error wine: Call from 0x7bc4ad90 to unimplemented function msvcrt.dll._snwprintf_s, aborting The game needed a native msvcrt, so I had installed one with winetricks, and it didn't export that function. So it seems that new gecko is incompatible with old msvcrt, and using native msvcrt as a workaround for bugs in wine's version is going to be harder than it used to be. Time to fix more of them msvcrt bugs, I guess... And/or find a more up to date msvcrt.dll for winetricks. or link gecko against msvcr80 or msvcr90 instead of msvcrt A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Missing backtrace when debugging a game
Le 23/04/2011 11:34, Jerome Leclanche a écrit : I'm currently trying to debug http://bugs.winehq.org/show_bug.cgi?id=25977. Even when running winedbg bin/release/loader.exe, this is what happens: Unhandled exception: page fault on read access to 0x in 32-bit code (0x00365327). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00365327 ESP:0033dd20 EBP:03d9 EFLAGS:00010246( R- -- I Z- -P- ) EBP has a strange value, so likely the current function has been compiled without frame pointer support (or has been screwed up) you need the debug info associated with that program to go further. do you have it ? or does the exec contain FPO information (winedump could be handy here) reading the stack shows that calling function is at 0x3670f9 so disas 0x3670f9 might give you better info A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: debugging wine itself with GDB
Le 12/04/2011 22:50, joed...@winedev1.nospam.homeip.net a écrit : I was taking a look at http://wiki.jswindle.com/index.php/Debugging_Wine to see how to debug wine with gdb, and there was reference to starting up gdb using wine-pthread, but I see no such executable now. I can attach gdb after it starts to run, but then do not get all the symbol information. There is wine-preloader but it seems to want an ELF file as an argument. there several ways to do it (assuming you've compiled yourself the sourcing and running from the source tree) 1/ using the gdb proxy from winedbg. you'll the a gdb front end, using winedbg's builtin gdb proxy wine winedbg --gdb winemine 2/ attach to a running process from shell prompt wine winemine /// get unix pid of wine, says 1234 (ps) from shell prompt gdb loader/wine from gdb prompt attach 1234 (some latest unix distro forbids attaching to a running process unless you're root or you've turned off this feature. refer to your distro doc if this happens) 3/ start process from gdb from shell prompt gdb loader/wine /// you may want here to set up some breakpoints first (gdb doesn't break at program startup routine, which winedbg does) /// don't use main as the break address target, you'll get the loader's one, not wine's exec which is bad /// WinMain is fine (unless your apps is CUI) from gdb prompt run winemine from gdb prompt exec-file loader/wine (say yes) from gdb prompt sharedlibrary /// you should be all set which method to use ? up to you g method 2 doesn't allow to debug program startup, but is a bit easier than 3/ to use method 2 or 3 gives you full gdb features, but you have to also understand some wine's internal (shared lib vs DLL) method 1/ allows you to get access to some of the wine internals (see docs) from gdb A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: dbghelp: get rid of a couple unused variables (try 2)
Le 11/04/2011 19:07, Austin English a écrit : IMO, you should keep the variable names in comment so that we know what we're talking about: /* version = */ dwarf2_parse_u2(ctx); or dwarf2_parse_u2(ctx); /* version */ A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH2/2] winmm: PlaySound concurrency cleanup.
sharing a global variable between threads without proper sync protection or atomic operation is the wrong thing to do moreover you're doing several unrelated changes in the same patch, please split up A+ 2011/3/28 joerg-cyril.hoe...@t-systems.com Hi, - PlaySound_Alloc does not call _Free anymore, so it does not use WINMM_cs anymore, which makes it easier to reason about use of critical sections. - psStopEvent was never used like an event rather than a boolean. - No need to muck with WHDR_DONE. - No need to keep the unused thread handle object around. - Abort the playloop in case of error, like I did for mciwave. The error may not be transient. - Free waveHdr and hEvent after closing hWave. Either you believe that WAVERR_STILLPLAYING can happen, then obviously waveHdr is in use and must not yet be freed, or you believe checking for STILLPLAYING is a waste of code because waveOutReset must have done its job. I should have added an ERR() message. One should think again about what to do in such a case. Why/when would sleep help? User-friendlier might be not to wait, not to free WaveHdr and accept to leak resources in such a case. Actually, waveOutClose can fail with STILLPLAYING because waveOutReset can fail. If you look at winealsa, you'll see it uses CreateEvent to synchronously wait for acknowledge of the message. Now guess what happens if CreateEvent fails because memory is tight? What happens in the app when waveOutClose's CreateEvent fails? It's always tough to reason about the many error paths. Regards, Jörg Höhle -- -- Eric Pouech
Re: Wine Gecko 1.2.0 beta1
- dbghelp fixes winedbg has problems with debug info from Gecko debug build, making debugging possibilities quite limited and backtraces lacking most of the calls. This is not related to Gecko release itself, but still it would be great to have it fixed. what are your favorite steps to reproduce this ? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH 4/4] [Kernel32]: add ability to load additional terminfo data from Wine registry
Le 19/01/2011 13:07, Alexandre Julliard a écrit : Eric Pouecheric.pou...@orange.fr writes: you mean hardwiring the missing keys (potentially different according to terminal type) in the code? If they depend on terminal type they belong in terminfo, not in the registry. as I said, terminfo is not fully populated it misses lots of ctrl-key (left arrow, right arrow...) and has not been updated lately most of the common text editors come with their own config files for example, /etc/inputrc has the missing bindings for libreadline (and of course it depends on $TERM) so, updating terminfo isn't the solution would you consider inclusion in hklm (instead of hkcu) ? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [Bug 25402] Woody Two Legs crashes with unimplemented function msvcr90.dll._wcslwr_s
the spec should read wstr instead of ptr A+ 2011/1/25 wine-b...@winehq.org http://bugs.winehq.org/show_bug.cgi?id=25402 Andrew Millington andrew.milling...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #5 from Andrew Millington andrew.milling...@gmail.com 2011-01-25 01:23:06 CST --- After applying http://source.winehq.org/patches/data/70240 it complains about unimplemented function d3dx9_36.dll.D3DXFloat32To16Array and that is bug #25769. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. --- You are receiving this mail because: --- You are watching all bug changes. -- -- Eric Pouech
Re: Alexandre Julliard : winedump: Try to load the PDB string table from file number 4 too.
2011/1/14 GOUJON Alexandre ale.gou...@gmail.com On 01/13/2011 09:11 PM, Eric Pouech wrote: Alexandre visiblement tu as un exemplaire de pdb sous la main différent de ceux que j'ai vu peux-tu me le passer (sauf si contrat spécifique CW bien sûr) j'ai toujours trouvé curieux les index constants pour certains streams dans les PDB, donc si j'en ai des différents, ca pourrait aider à trouver l'indirection (potentielle) Hi Eric, I do speak French so I can understand your mail but we are a minority here to do so. Even if you're talking to AJ (does he even speak French ?), please use English. I think people would be glad to understand you :) the mail was not intended to be on wine-devel (hence the French) sorry about the noise A+ -- -- Eric Pouech
Re: Alexandre Julliard : winedump: Try to load the PDB string table from file number 4 too.
Le 12/01/2011 20:16, Alexandre Julliard a écrit : Module: wine Branch: master Commit: 4f574ee942be99c7401a3bef472a81d0f2bb0b5b URL: http://source.winehq.org/git/wine.git/?a=commit;h=4f574ee942be99c7401a3bef472a81d0f2bb0b5b Author: Alexandre Julliardjulli...@winehq.org Date: Wed Jan 12 10:45:54 2011 +0100 winedump: Try to load the PDB string table from file number 4 too. Alexandre visiblement tu as un exemplaire de pdb sous la main différent de ceux que j'ai vu peux-tu me le passer (sauf si contrat spécifique CW bien sûr) j'ai toujours trouvé curieux les index constants pour certains streams dans les PDB, donc si j'en ai des différents, ca pourrait aider à trouver l'indirection (potentielle) A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [4/7] kernel32/tests: Demonstrate an input event handling peculiarity with WriteConsoleInputW.
Hi Andrew, I think the test should be enhanced by checking the information about mouse position it seems that windows coalesce two mouse messages, but does it also occur when the position is different (a cursory look seems to indicate that you resend the same coordinate for mouse move) I'd expect coalesce operation to happen only if coordinates are the same A+ 2011/1/11 Andrew Nguyen angu...@codeweavers.com --- dlls/kernel32/tests/console.c | 165 +++-- 1 files changed, 159 insertions(+), 6 deletions(-) -- -- Eric Pouech
Re: [PATCH 3/2] msvcrt: Implement _wcslwr_s
Le 07/01/2011 15:42, Detlef Riekenberg a écrit :
based on _strlwr_s
This let Radiotracker go further
/*
+ * _wcslwr_s (MSVCRT.@)
+ */
+int CDECL _wcslwr_s(WCHAR *str, MSVCRT_size_t len)
+{
+WCHAR *ptr = str;
+
+if (!str || !len)
please use the MSVCRT_CHECK_PMT as done in the other _s msvcrt's functions
A+
--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot. (Douglas Adams)
Re: 64-bit Notepad2 crashes
ELF 7f3aa090b000-7f3aa0c3d000 Export libwine.so.1 if you've compiled wine yourself, it's strange that libwine.so doesn't contain any dwarf information maybe you're loading another instance of libwine? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: wine-1.3.8 regression for the curses backend to wineconsole
Le 11/12/2010 00:04, Alan W. Irwin a écrit : The command wineconsole --backend=curses cmd hangs with the following error message for 1.3.8: err:ntdll:RtlpWaitForCriticalSection section 0x7ee17dec ? wait timed out in thread 0065, blocked by , retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7ee17dec ? wait timed out in thread 004d, blocked by , retrying (60 sec) There are no such issues for the default wineconsole backend, but I have always preferred using the curses backend because cut and paste was available for it. That backend worked fine (according to my notes) for wine-1.1.41. no need to open a PR for this it's already fixed in 1.3.9 A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH] console: fix output for console handles opened with GENERIC_WRITE access
this has already been discussed on wine-devel a couple of days ago
the right fix is either to fix WriteConsole so that it doesn't require
read access (actually FILE_READ_PROPERTIES), or to grant this access user
side
so the fix in the server will be rejected
A+
2010/11/12 Martin Wilck martin.wi...@particle-dynamics.de
Writing to a console handle obtained with a requested access mode
GENERIC_WRITE
produces no output. This happens because get_console_mode() requires
FILE_READ_PROPERTIES access on the handle, which a handle created with
GENERIC_WRITE doesn't have.
This affects many Microsoft console applications, e.g. nmake and cl from
VC++
express 2005.
It can be tested with the following minimal test program (compiled with
VC 2005 run with native mscvr80):
int main(void)
{
_cprintf(Hi.\n);
return 0;
}
This behaves as follows:
trace:console:OpenConsoleW (LCONOUT$, 0x4000, 0, 3)
0009: open_console( from=0001, access=4000, attributes=,
share=3 )
0009: open_console() = 0 { handle=0028 }
trace:console:WriteConsoleW 0x2b LH 1 0x33fb78 (nil)
0009: get_console_mode( handle=0028 )
0009: get_console_mode() = ACCESS_DENIED { mode=0, is_bare=0 }
Because of the ACCESS_DENIED, this program produces no output on current
wine.
This patch fixies this with a new map_access() function for the console.
Signed-off-by: Martin Wilck martin.wi...@particle-dynamics.de
---
server/console.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
--
--
Eric Pouech
Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)
Le 10/11/2010 17:34, Alexandre Julliard a écrit : Eric Pouecheric.pou...@orange.fr writes: msvcr90 doesn't set msvcrt's errno in case of error, while msvcrt does Hence the wrappers inside msvcr90 around _itoa_s and _itow_s calls. Do you have an app that depends on this? no, just the current tests that fail A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)
Le 10/11/2010 22:32, Alexandre Julliard a écrit : Eric Pouecheric.pou...@orange.fr writes: Le 10/11/2010 17:34, Alexandre Julliard a écrit : Eric Pouecheric.pou...@orange.fr writes: msvcr90 doesn't set msvcrt's errno in case of error, while msvcrt does Hence the wrappers inside msvcr90 around _itoa_s and _itow_s calls. Do you have an app that depends on this? no, just the current tests that fail Then I'd say don't bother replicating that for now. Setting errno when getting invalid parameters seems quite reasonable. so we stop testing that we didn't set errno in msvcrN0 for _s functions? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)
to sum up the recent discrepencies between msvcrt and msvcrN0 Dlls: - msvcrt doesn't raise exception on _s functions while msvcrN0 does - (likely) in _s functions returning an errno_t value, msvcrt does set errno to the returned value, while msvcrN0 doesn't change the errno value (tested on _itoa_s and wcsncat_s) I wonder if should challenge the current scheme of forwarding all APIs from msvcrN0 to msvcrt (and writing wrappers in msvcr90 to cope with the various discrepencies) we could let msvcrt behave differently when loaded from our msvcrN0 DLLs than when loaded standalone, and factorize the discrepencies within msvcrt itself comments welcome A+ -- Eric Pouech
Re: [PATCH 10/14] [Msvcrt*]: implemented _vc(w)printf
va_copy only exists in C99
wine requires C89 only
A+
2010/11/8 David Laight da...@l8s.co.uk
On Wed, Nov 03, 2010 at 10:53:55AM +0100, Alexandre Julliard wrote:
Eric Pouech eric.pou...@orange.fr writes:
+int CDECL _vcprintf(const char* format, __ms_va_list xvalist)
{
char buf[2048], *mem = buf;
int written, resize = sizeof(buf), retval;
- __ms_va_list valist;
+ __ms_va_list valist = xvalist;
You can't copy a valist. This needs to be integrated properly with the
other printf functions.
Well, you can if you can find a va_copy() function .
David
--
David Laight: da...@l8s.co.uk
--
--
Eric Pouech
Re:
Le 07/11/2010 23:06, Greg Geldorp a écrit : From: Eric Pouech how come I got two different test results for the same patch ? moreover one is perfectly ok, while the other shows strange results any idea ? Yeah, that's a bit weird. The only thing I can think of is some kind of timing issue, but looking at the code that seems unlikely in this case. So basically, I don't have a clue. Ge. Ge, sorry for the noise, but I've mixed the outputs one is for the tests in dlls/msvcrt, the second for the tests in dlls/msvcr90... which give different results g so the testbot looks perfectly correct here... while the various msvcrt isn't A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Strange test bot results
Hi Ge, how come I got two different test results for the same patch ? moreover one is perfectly ok, while the other shows strange results any idea ? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams) ---BeginMessage--- VM StatusNumber of test failures WINEBUILDcompleted W98SEcompleted 0 WNT4WSSP6completed 0 W2KPROSP4completed 0 WXPPROSP3completed 0 W2K3R2SESP2 completed 0 WVISTAADMcompleted 0 W2K8SE completed 0 W7PROcompleted 0 W7PROX64 completed 0 W7PROX64 completed 0 === WINEBUILD (build) === No build failures found === W98SE (32 bit string) === No test failures found === WNT4WSSP6 (32 bit string) === No test failures found === W2KPROSP4 (32 bit string) === No test failures found === WXPPROSP3 (32 bit string) === No test failures found === W2K3R2SESP2 (32 bit string) === No test failures found === WVISTAADM (32 bit string) === No test failures found === W2K8SE (32 bit string) === No test failures found === W7PRO (32 bit string) === No test failures found === W7PROX64 (32 bit string) === No test failures found === W7PROX64 (64 bit string) === No test failures foundApplying patch Checking patch /var/lib/winetestbot/wine-git/dlls/msvcr90/tests/msvcr90.c... Checking patch /var/lib/winetestbot/wine-git/dlls/msvcrt/string.c... Checking patch /var/lib/winetestbot/wine-git/dlls/msvcrt/tests/string.c... Applied patch /var/lib/winetestbot/wine-git/dlls/msvcr90/tests/msvcr90.c cleanly. Applied patch /var/lib/winetestbot/wine-git/dlls/msvcrt/string.c cleanly. Applied patch /var/lib/winetestbot/wine-git/dlls/msvcrt/tests/string.c cleanly. Making test executable make: Entering directory `/var/lib/winetestbot/build-mingw32/dlls/msvcrt/tests' i686-pc-mingw32-gcc -c -I../../../../wine-git/dlls/msvcrt/tests -I. -I../../../../wine-git/include -I../../../include -I../../../../wine-git/include/msvcrt -I../../../../wine-git/dlls/msvcrt/tests/.. -DWINE_STRICT_PROTOTYPES -D_REENTRANT -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -g -O2 -D_WIN32 -fno-builtin -o string.o ../../../../wine-git/dlls/msvcrt/tests/string.c ../../../../build-native/tools/winegcc/winegcc -b i686-pc-mingw32 -B../../../../build-native/tools/winebuild --sysroot=../../.. -fasynchronous-unwind-tables -mno-cygwin cpp.o data.o dir.o environ.o file.o headers.o heap.o locale.o misc.o printf.o scanf.o signal.o string.o time.o testlist.o -o msvcrt_test.exe ../../../libs/port/libwine_port.a make: Leaving directory `/var/lib/winetestbot/build-mingw32/dlls/msvcrt/tests' Making test executable make: Entering directory `/var/lib/winetestbot/build-mingw64/dlls/msvcrt/tests' x86_64-w64-mingw32-gcc -c -I../../../../wine-git/dlls/msvcrt/tests -I. -I../../../../wine-git/include -I../../../include -I../../../../wine-git/include/msvcrt -I../../../../wine-git/dlls/msvcrt/tests/.. -DWINE_STRICT_PROTOTYPES -D_REENTRANT -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -fno-builtin -o string.o ../../../../wine-git/dlls/msvcrt/tests/string.c ../../../../build-native/tools/winegcc/winegcc -b x86_64-w64-mingw32 -m64 -B../../../../build-native/tools/winebuild --sysroot=../../.. -fasynchronous-unwind-tables -mno-cygwin cpp.o data.o dir.o environ.o file.o headers.o heap.o locale.o misc.o printf.o scanf.o signal.o string.o time.o testlist.o -o msvcrt_test.exe ../../../libs/port/libwine_port.a make: Leaving directory `/var/lib/winetestbot/build-mingw64/dlls/msvcrt/tests'msvcrt:string start - - string.c:444: Tests skipped: strcpy_s not found string.c:498: Tests skipped: strcat_s not found string.c:562: Tests skipped: _mbsnbcpy_s not found string.c:609: Tests skipped: wcscpy_s not found string.c:656: Tests skipped: _wcsupr_s not found string.c:940: Tests skipped: strnlen not found string.c:971: Tests skipped: _strtoi64 or _strtoui64 not found string.c:1220: Tests skipped: Japanese_Japan.932 locale not available string.c:1264: Tests skipped: Skipping _gcvt tests string.c:1300: Tests skipped: Skipping _itoa_s tests string.c:1399: Tests skipped: Skipping _strlwr_s tests string.c:1458: Tests skipped: skipping wcsncat_s tests string.c:1497: Tests skipped: Skipping _mbsnbcat_s tests string.c:1622: Tests skipped: Skipping _ultoa_s tests string: 1248 tests executed (0 marked as todo, 0 failures), 14 skipped. msvcrt:string done (0)msvcrt:string start - - string.c:444: Tests skipped: strcpy_s not found string.c:498: Tests skipped: strcat_s not found string.c:562: Tests skipped: _mbsnbcpy_s not found string.c:609: Tests skipped: wcscpy_s not found string.c:656: Tests skipped: _wcsupr_s not found
Re: [PATCH 10/14] [Msvcrt*]: implemented _vc(w)printf
Le 03/11/2010 10:53, Alexandre Julliard a écrit :
Eric Pouecheric.pou...@orange.fr writes:
+int CDECL _vcprintf(const char* format, __ms_va_list xvalist)
{
char buf[2048], *mem = buf;
int written, resize = sizeof(buf), retval;
- __ms_va_list valist;
+ __ms_va_list valist = xvalist;
You can't copy a valist. This needs to be integrated properly with the
other printf functions.
I therefore suspect MSVCRT_vfprintf (in file.c) to be buggy as well as
the va_list isn't reset between calls to MSVCRT_vsnprintf
A+
--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH] [Server]: fix access rights for console creation (#24792)
2010/10/27 Alexandre Julliard julli...@winehq.org Eric Pouech eric.pou...@orange.fr writes: +if (access GENERIC_READ)access |= FILE_GENERIC_READ; +/* FIXME: we add FILE_READ_PROPERTIES access even in write-only mode. + * As tested on Windows, this is not correct (ie GetConsoleMode() on with GENERIC_WRITE only + * access fails). + * But, this is currently needed as part of kernel32/console.c client side code relies on the + * fact that it can read properties: lots of 'set' functions like WriteConsole, + * ScrollConsoleScreenBuffer, SetConsoleCursorPosition (and many others) do call 'get' + * functions. + */ These should be fixed then. this will require moving more than half a dozen of operations done client side to the server so that it does read the attributes that's both: 1/ a tremendous change 2/ will either move most of console handling into the server, or more the access control on the client side. and I'd bet none of those two options you'll like A+ -- -- Eric Pouech
Re: Debugging 64-bit Wine Apps with winedbg
Le 24/09/2010 05:12, Peter Urbanec a écrit :
On 24/09/10 06:43, Eric Pouech wrote:
sure send me the .exe+pdb (+source) I'll have a look at it
Source and binaries sent to Eric in private, so that the list isn't
polluted with megabytes of binaries. If anyone else is interested in
having a copy, please let me know and I'll forward it in private.
Cheers,
Peter Urbanec
with the patchset I've just sent, I get something like:
Thread 0x0021 sleeping 200ms
Thread 0x0022 sleeping 200ms
Thread 0x0020 sleeping 240ms
Thread 0x0023 sleeping 200ms
Thread 0x0021 *** C R A S H I N G ***
wine: Unhandled page fault on write access to 0x at address
0x1400010b3 (thread 0021), starting debugger...
Thread 0x0022 *** C R A S H I N G ***
Thread 0x0023 *** C R A S H I N G ***
WineDbg starting on pid 001f
Thread 0x0020 *** C R A S H I N G ***
First chance exception: page fault on write access to 0x in
64-bit code (0x0001400010b3).
Register dump:
rip:0001400010b3 rsp:7feb8997fbb0 rbp:000140001a20
eflags:00010202 ( R- -- I - - - )
rax: rbx:7feb8bb55000 rcx:000140084478
rdx:000140084480
rsi:7feb8b937401 rdi:7feb8997fbe0 r8:0001
r9:0010d640 r10:7feb8997e850
r11:7feb8997e820 r12: r13:7b86f590
r14:000140d8 r15:7feb8bb5
Stack dump:
0x7feb8997fbb0: 00014006ed20 0020
0x7feb8997fbc0: 7feb8997fa60 0028
0x7feb8997fbd0: 7feb8997fc30 0020
0x7feb8997fbe0: 7feb8997fce0 000140001223
0x7feb8997fbf0: 7feb8997fc30 0010
0x7feb8997fc00: 000140001014
0x7feb8997fc10: 0004 7feb8997fc84
0x7feb8997fc20:
0x7feb8997fc30: 00f0cc01
0x7feb8997fc40: 00c8cc01
0x7feb8997fc50: 00c8cc01
0x7feb8997fc60: 00c8cc01
Backtrace:
=0 0x0001400010b3 Boom::crash_func+0x83(void_ptr=0x7feb8997fc30,
arg_ref=0x7feb8997fc30, tid=32)
[z:\eyeon\u_drive\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:29]
in multiplethreads (0x000140001a20)
1 0x000140001223 main+0x142(argc=1, argv=0x7feb89771130,
thisThread=0xfffe, threadHandle={0x1c, 0x20, 0x24},
threadID=35, oldpri=0, a={{cause_crash=true, delay=240,
pointer=0x0(nil)}, {cause_crash=true, delay=200, pointer=0x0(nil)},
{cause_crash=true, delay=200, pointer=0x0(nil)}, {cause_crash=true,
delay=200, pointer=0x0(nil)}})
[z:\eyeon\u_drive\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:63]
in multiplethreads (0x000140001a20)
2 0x000140001c5c __tmainCRTStartup+0x21b(winver=1281, mainret=0,
osver=2600, winminor=1, posvi=0x7feb8ba24070, osplatform=2,
managedapp=0, initret=0, winmajor=5)
[f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:327] in
multiplethreads (0x000140001a20)
3 0x000140001a2e mainCRTStartup+0xd()
[f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c:195] in
multiplethreads (0x000140001a20)
4 0x7b86f64f start_process+0xbe(peb=0x7feb8bb55000)
[/home/eric/work/wine/dlls/kernel32/process.c:963] in kernel32
(0x000140001a20)
5 0x7feb8abfe43e call_thread_func+0x6d(entry=is not available,
arg=is not available, frame=is not available)
[/home/eric/work/wine/dlls/ntdll/signal_x86_64.c:3036] in ntdll
(0x000140001a20)
6 0x7feb8abfd73e call_thread_entry_point+0x29() in ntdll
(0x000140001a20)
7 0x7feb8abd0da6 start_process+0x15(kernel_start=0x7feb8997fec8)
[/home/eric/work/wine/dlls/ntdll/loader.c:2610] in ntdll
(0x000140001a20)
8 0x7feb8b611ea3 wine_call_on_stack+0x12() in libwine.so.1
(0x000140001a20)
9 0x7feb8b611eb9 wine_switch_to_stack+0x8(func=0x7feb8997fec8,
arg=0x0(nil), stack=0x140084480)
[/home/eric/work/wine/libs/wine/port.c:83] in libwine.so.1
(0x000140001a20)
10 0x7feb8abd5294
LdrInitializeThunk+0x3d3(kernel_start=0x7b86f590, unknown2=is not
available, unknown3=is not available, unknown4=is not available)
[/home/eric/work/wine/dlls/ntdll/loader.c:2666] in ntdll
(0x000140001a20)
11 0x7b874185 __wine_kernel_init+0x914()
[/home/eric/work/wine/dlls/kernel32/process.c:1163] in kernel32
(0x000140001a20)
12 0x7feb8abd5824 __wine_process_init+0x253()
[/home/eric/work/wine/dlls/ntdll/loader.c:2876] in ntdll
(0x000140001a20)
13 0x7feb8b610a0f wine_init+0x28e(argc=is not available,
argv=0x7fff9949d238, error=, error_size=is not available)
[/home/eric/work/wine/libs/wine/loader.c:711] in libwine.so.1
(0x000140001a20)
14 0x7bf00cf1 main+0x80(argc=2, argv=0x7fff9949d238)
[/home/eric/work/wine/loader/main.c:218] in wine-loader
(0x000140001a20)
15 0x7feb8b087c4d __libc_start_main+0xfc(main=is not
available, argc=is not available
Re: [PATCH1/3] include/winternl: Add Logical Processor Information to SYSTEM_CPU_INFORMATION
SystemCpuInformation seems not defined anywhere outside Wine. It's not defined on MSDN, neither can it be found on any Wine-unrelated Documentations/Source-codes or Documentations. If you have any links or documentation for SystemCpuInformation, could you send them please ? If i can't extend the struct, i think it would be easier to just move the parser into kernel32/process as well and avoid modifiying this interface as NtQuerySystemInformation is marked as deprecated on MSDN anyway. try SystemProcessorInformation and SYSTEM_PROCESSOR_INFORMATION (instead of SystemCpuInformation and SYSTEM_CPU_INFORMATION) and you'll see that it's not Wine specific. so you cannot extend them moreover, don't trust MSDN... they're simply saying that if there's the same API in kernel32 it should be prefered over it's ntdll counterpart... regarding your patch, the core of the work has to be done in ntdll. you just have to find the correct API in ntdll that does the job you're not using the right one (at least for the class of the query) for example, SystemNumaProcessorMap could help you... (even I coudn't find some docs about the structures, but I didn't search a lot), and reverse engineering (using ntdll as a blackbox) may be of some help A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Debugging 64-bit Wine Apps with winedbg
I'm happy to provide test source code, 64-bit and 32-bit binaries and matching PDB files, if anyone is interested in looking at the issue. sure send me the .exe+pdb (+source) I'll have a look at it I only tested winedbg on 64bit with gcc A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Console issues in recent git
Le 12/09/2010 14:09, Jerome Leclanche a écrit : Set a 1440x900 virtual desktop in winecfg. what do you mean by: - run a program in winedbg (in my case, it was in a virtual desktop, too) = does it mean you got 2 virtual desktops ? or got a shell running in one virtual desktop ? - (?) Terminate process in the virtual desktop when it asks = where does this prompt come from ? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Console issues in recent git
Le 12/09/2010 00:26, Jerome Leclanche a écrit : Hi Eric, Ive been running your patch for a couple of days and I just noticed another case where it's not resetting terminal properties: - Run a program in winedbg (in my case, it was in a virtual desktop, too) - Wait for program to crash - Hit ctrl-c - (?) Terminate process in the virtual desktop when it asks - When exiting, terminal isn't cleared I haven't really managed to repro, but these are the steps that lead to my issue. Hope it helps. J. Leclanche what do you mean by virtual desktop ? A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Console issues in recent git
Le 09/09/2010 18:13, Jerome Leclanche a écrit : Eric, When running a program with r in winedbg, I get: fixme:winedbg:dbg_run_debuggee Re-running current program with \r as args is broken Does this have anything to do with the EOL conversion issues? no, it has been broken for years (if you really used 'r' or 'r foo bar' as command in winedbg) A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Console issues in recent git
does the attached patch help with some of the concerns ?
I/ it should allow typing in the console (for all GUI programs) and
still see output get buffer when the programs exits
II/ reduce the number of cases where the console is in raw mode after
wine exits
Not all the cases are supposed to be fixed.
For example, this is one example of what still doesn't work
but in this case, the first program is killed at the same time as
winedbg exits, which shouldn't the case)
what shall remain not fixed is the case where:
- pgm A is started from shell command line
- pgm A spawns child B
- B is a CUI and tries to interact with the console by reading the input
- A dies
I still sometimes see it when exiting winedbg after it has been launched
upon a fault in a running program... but, something goes wrong here as
quitting winedbg (B) shouldn't kill the program beeing debugged (A)
what's not yet fixed :
- regression in EOF management
A+
--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot. (Douglas Adams)
diff --git a/dlls/kernel32/console.c b/dlls/kernel32/console.c
index 9ac7018..5cc5ae1 100644
--- a/dlls/kernel32/console.c
+++ b/dlls/kernel32/console.c
@@ -54,6 +54,9 @@
#include excpt.h
#include console_private.h
#include kernel_private.h
+#ifdef HAVE_TERMIOS_H
+#include termios.h
+#endif
WINE_DEFAULT_DEBUG_CHANNEL(console);
@@ -146,6 +149,78 @@ static BOOL get_console_mode(HANDLE conin, DWORD* mode,
BOOL* bare)
return ret;
}
+static struct termios S_termios;
+static BOOL S_termios_raw /* = FALSE */;
+
+static int get_console_bare_fd(HANDLE hin)
+{
+BOOLis_bare;
+int fd;
+
+if (get_console_mode(hin, NULL, is_bare) is_bare
+wine_server_handle_to_fd(hin, 0, fd, NULL) == 0 /*STATUS_SUCCESS*/)
+return fd;
+return -1;
+}
+
+static BOOL save_console_mode(HANDLE hin)
+{
+int fd;
+BOOLret;
+
+if ((fd = get_console_bare_fd(hin)) == -1) return FALSE;
+ret = tcgetattr(fd, S_termios) = 0;
+close(fd);
+return ret;
+}
+
+static BOOL put_console_into_raw_mode(HANDLE hin)
+{
+intfd;
+
+if ((fd = get_console_bare_fd(hin)) == -1) return FALSE;
+
+RtlEnterCriticalSection(CONSOLE_CritSect);
+if (!S_termios_raw)
+{
+struct termios term = S_termios;
+
+term.c_lflag = ~(ECHO | ECHONL | ICANON | IEXTEN);
+term.c_iflag = ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON);
+term.c_cflag = ~(CSIZE | PARENB);
+term.c_cflag |= CS8;
+/* FIXME: we should actually disable output processing here
+ * and let kernel32/console.c do the job (with support of
enable/disable of
+ * processed output)
+ */
+/* term.c_oflag = ~(OPOST); */
+term.c_cc[VMIN] = 1;
+term.c_cc[VTIME] = 0;
+S_termios_raw = tcsetattr(fd, TCSANOW, term) = 0;
+}
+RtlLeaveCriticalSection(CONSOLE_CritSect);
+
+close(fd);
+return S_termios_raw;
+}
+
+/* put back the console in cooked mode iff we're the process which created the
bare console
+ * we don't test if thie process has set the console in raw mode as it could
be one of its
+ * child who did it
+ */
+static BOOL put_console_into_cooked_mode(HANDLE hin)
+{
+int fd;
+BOOLret;
+
+if (RtlGetCurrentPeb()-ProcessParameters-ConsoleHandle !=
KERNEL32_CONSOLE_SHELL)
+return TRUE;
+if ((fd = get_console_bare_fd(hin)) == -1) return FALSE;
+ret = tcsetattr(fd, TCSANOW, S_termios) = 0;
+close(fd);
+return ret;
+}
+
/**
* GetConsoleWindow [kernel...@] Get hwnd of the console window.
*
@@ -1080,6 +1155,7 @@ static enum read_console_input_return
read_console_input(HANDLE handle, PINPUT_R
if (bare)
{
+put_console_into_raw_mode(handle);
if (WaitForSingleObject(GetConsoleInputWaitHandle(), 0) !=
WAIT_OBJECT_0)
{
ret = bare_console_fetch_input(handle, timeout);
@@ -2893,6 +2969,7 @@ DWORD WINAPI GetConsoleProcessList(LPDWORD processlist,
DWORD processcount)
BOOL CONSOLE_Init(RTL_USER_PROCESS_PARAMETERS *params)
{
+memset(S_termios, 0, sizeof(S_termios));
if (params-ConsoleHandle == KERNEL32_CONSOLE_SHELL)
{
HANDLE conin;
@@ -2956,7 +3033,10 @@ BOOL CONSOLE_Init(RTL_USER_PROCESS_PARAMETERS *params)
if (!params-hStdInput)
params-hStdInput = INVALID_HANDLE_VALUE;
else if (VerifyConsoleIoHandle(console_handle_map(params-hStdInput)))
+{
params-hStdInput = console_handle_map(params-hStdInput);
+save_console_mode(params-hStdInput);
+}
if (!params-hStdOutput)
params-hStdOutput = INVALID_HANDLE_VALUE;
@@ -2970,3 +3050,10 @@ BOOL CONSOLE_Init(RTL_USER_PROCESS_PARAMETERS *params)
return TRUE;
}
+
+BOOL CONSOLE_Exit(void)
+{
+/* the console
Re: Console issues in recent git
Hi,
after the console patch series, it appears a couple of problems are left
over:
to summarize, the problems with their status:
A/ when a program is running, no echo is seen for characters being typed.
B/ after running a wine program, the console is a bad shape and needs
'reset' to get back in a sane state.
Status
A/ IMO, it's barely a bug as you can't make an hypothesis about what a
program will do with character input. However, it's a change from
previous behavior as one could see the echo. This only happens when the
running program doesn't read its input. However, since now wine runs in
raw console mode, it's likely the typed characters will not be useful to
the shell when the program exits (as the shell will run in cooked mode
and will start with an empty buffer). Low priority for a fix (if any)
B/ actually, it's likely a race (in the simple way of running one single
program) about resetting the console in decent shape. Could the folks
having the issue try the attached patch (file conclean) to see if it
helps ? (I never could reproduce it here, tested with konsole xterm.
If you still see the issue, please detail console and shell program)
Clearly an annoying impact for most users, need fixing.
Actually, there's another issue with the same symptoms:
1- program A is launched from shell
2- program A starts another program B (for example winedbg when a fault
occurs)
3- at this point, both A B can read/write to the console
4- program A exits. As it way the group leader, B is set into the
background and loses (read) access to the console.
5- When B exits, as it no longer has access to the console, the state of
the console cannot be reset to normal
this was happening before the patch series, but as we didn't tweak the
console, it was just fine (except that some program dies when in the
background, eg winedbg)
fix will not be 100% easy
among the potential fixes:
S1: no longer do the console attribute management in server, but only in
kernel32, and only for the livespan of the process creating the bare
console. this means that the console will not be accessible to the
children of this process after its death (but I don't see how to do it
anyway)
S2: when the process that created the bare console, it's about to
terminate it should wait for all its children to die. This would require
a cloak of invisibility (from the win32 space) to let the other
win32-process see that it actually died.
S3: combine S1 and S2
comments welcome
also, I may have forgotten (or misunderstood) some issue reports. Don't
hesitate to jump in.
NB: I also have a patchset ready that shall enable key/arrows support in
bare console mode (with history bells whistles... handy for any
program with a CLI)
A+
--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot. (Douglas Adams)
diff --git a/server/console.c b/server/console.c
index 2ca6bd4..ea262fd 100644
--- a/server/console.c
+++ b/server/console.c
@@ -481,6 +481,17 @@ int free_console( struct process *process )
return 1;
}
+void close_console( struct process* process)
+{
+struct console_input* console = process-console;
+
+if (console console_input_is_bare(console) --console-num_proc == 0)
+{
+process-console = NULL;
+release_object(console);
+}
+}
+
/* let process inherit the console from parent... this handle two cases :
* 1/ generic console inheritance
* 2/ parent is a renderer which launches process, and process should
attach to the console
diff --git a/server/process.c b/server/process.c
index a3aa586..10f4bd7 100644
--- a/server/process.c
+++ b/server/process.c
@@ -566,6 +566,7 @@ static void terminate_process( struct process *process,
struct thread *skip, int
struct thread *thread;
grab_object( process ); /* make sure it doesn't get freed when threads
die */
+close_bare_console( process );
restart:
LIST_FOR_EACH_ENTRY( thread, process-thread_list, struct thread,
proc_entry )
{
diff --git a/server/process.h b/server/process.h
index cee7be9..e8546e6 100644
--- a/server/process.h
+++ b/server/process.h
@@ -126,6 +126,7 @@ extern void enum_processes( int (*cb)(struct process*,
void*), void *user);
/* console functions */
extern void inherit_console(struct thread *parent_thread, struct process
*process, obj_handle_t hconin);
extern int free_console( struct process *process );
+extern int close_bare_console( struct process *process );
extern struct thread *console_get_renderer( struct console_input *console );
/* process tracing mechanism to use */
Re: Console issues in recent git
to summarize a bit: - wineserver doesn't reset the terminal attributes if it's killed (to be fixed) - command line edition is not supported. it was not supported either in previous console code (outside of wineconsole). this is to be provided in next patches - I have no idea on the blank outputs. is the wine program you're testing the first one to be launched ? - enter issues should be looked at (sounds like bad \r, \n, \n\r conversions) A+ 2010/9/2 Octavian Voicu octavian.vo...@gmail.com On Thu, Sep 2, 2010 at 4:29 AM, Jerome Leclanche adys...@gmail.com wrote: Anyone else's terminal emulators really acting up since the last git batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if there is a wine process running, until it's killed. This is probably a konsole bug, but still... Actually, I've run into this yesterday, not sure what the cause is (could be Eric's console patches, not cleaning up properly). To fix it, type `reset' in the offending terminal (even if you don't see anything you type, just type enterresetenter). It will reset all terminal attributes. Octavian -- -- Eric Pouech
Re: Console issues in recent git
Le 02/09/2010 03:29, Jerome Leclanche a écrit : Anyone else's terminal emulators really acting up since the last git batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if there is a wine process running, until it's killed. This is probably a konsole bug, but still... CC eric. -- J. Leclanche not really is the program you're running a CUI or GUI exec ? if it's a CUI, then it's normal as it's supposed to get all your current input if it's a GUI (without a win32 console), then it's more questionnable A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: dbghelp: Remove unused functions?
Le 28/08/2010 15:13, Andrew Talbot a écrit : Hi, Static functions pe_get_sect() and pe_get_sect_size() in dbghelp/pe_module.c are not called. May I remove them or does anyone have plans for them? Thanks, Andy. you can remove them. they have been superseeded by the ones in image_private.h A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: PDB files generated by Intel C++ Compiler
Le 19/08/2010 19:36, Peter Urbanec a écrit : I have some x64 binaries and associated PDBs that have been generated using Intel C++ Compiler 11.1. These PDBs cause issues such as this: 1 0x781cc1ba in msvcr80 (+0x9c1b9) (0x7ff047a4c840) fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 2 0x6189a00d in lua5.1 (+0xa00c) (0x7ff047a4c840) Now, from a quick look at mscvpdb.h, it looks like these PDBs contain datatypes with 64-bit near pointers, however wine does not seem to understand this mode. How would one go about adding support for this type of PDB? I actually don't have access to the Intel C++ Compiler to do much testing. :-( if the near 64bit pointer, is a 64bit pointer, that's trivial, just add the needed types to dlls/dbghelp/msc.c and include/dbghelp.h with things like: cv_basic_types[T_64PVOID] = cv_basic_types[T_PVOID]; if it's something else, then that's another issue... A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Wine64 debugger
the assertion `addr-Mode == AddrModeFlat' failed is likely an address returned by dbghelp which is not properly initialized. Could you send me off line the .exe (and associated DLL if any) so that I can check it TIA 2010/8/17 Peter Urbanec winehq@urbanec.net Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as ./wine Test1.exe. When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr-Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x7fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec -- -- Eric Pouech
Re: Wine users with a CD-ROM drive, please test
Jörg-Cyril : may be the driver doesn't support TMSF, and from/to fields must be provided in MSF would you mind trying that ? A+ -- -- Eric Pouech
Re: mmio: Ensure FOURCC string conversions are null-terminated.
the explanations for the bug fix look really strange all the printf use %4.4s form, which will limit output to only 4 chars, whatever the string is terminated or not so the crash doesn't come from here looking quickly at the patch, several remark arise - in the second third modification to the TRACE call, are you sure the test to srcType is relevant (I don't have the code handy, but it may be a wrong cut paste) - more importantly, as the %4.4s form implies a 4 char strings, the strings used in case of NULL value must be 4 characters long, instead we may get into trouble A+ 2010/7/18 Tim Cadogan-Cowper tccow...@yahoo.com.au Three TRACE debug calls in the mmioDescend function of mmio.c attempt to print FOURCC data, by directly casting it to LPCSTR. This is dangerous as: (i) FOURCC data types are DWORDs, i.e. four bytes (one for each char), with no null terminating byte (see http://msdn.microsoft.com/en-us/library/dd375802%28VS.85%29.aspx); and (ii) it assumes the byte order on the host architecture is little endian. Because the LPCSTR casts are not necessarily null-terminated there will occasionally be buffer overflows in mmio's TRACE debug strings, with a consequent crash to desktop and debug output beginning with 'wine_dbg_vprintf: debugstr buffer overflow...' For a consistent and predictable case where this occurs, see Bug 10280 Oblivion: Horse Armour Crash (http://bugs.winehq.org/show_bug.cgi?id=10280). This patch fixes the problem (and any crashes caused by it) by using a new internal function in mmio - mmioFOURCCToString - which converts FOURCC data to strings that are correctly null-terminated and respect byte order. I have tested with Oblivion and can confirm it fixes Bug 10280 on my machine (ubuntu 10.04). Furthermore the patch will ensure that chunk IDs and fourccTypes are correctly printed in the mmio debug channel (at the moment they are not). Tim -- -- Eric Pouech
Re: Please review: Patch for non-Linux serial set_baud_rate()
Le 30/06/2010 20:26, Ken Thomases a écrit : On Jun 30, 2010, at 11:47 AM, Ken Thomases wrote: I happened to stumble across some code which didn't look quite right in dlls/ntdll/serial.c. However, I have no expertise in serial comms or termios. Also, I have no means to test the change I propose. On the other hand, the change seems clearly right and conforms to what I learn from man pages, etc. On re-reading, I realize I didn't say what the nature of the problem and change are: set_baud_rate() needs to poke at a termios structure and enter the desired baud rate into its fields. However, the baud rate is represented differently on Linux than on other platforms. This is detected with an #ifdef CBAUD test. On Linux, the baud rate goes into the c_cflag field; elsewhere, it goes into dedicated c_ospeed and c_ispeed fields. At some point, somebody extended the non-Linux branch to support higher baud rates, to match capability that the Linux branch had. However, they seem to have just copied the Linux-appropriate code and pasted it into the non-Linux branch. So, the code is stuffing the baud rate into the c_cflag field and not the c_ospeed field. In the non-Linux branch, the high baud rate cases of the switch statement don't match the lower baud rate cases. My proposed change sets the baud rate via the c_ospeed field for all cases on the non-Linux branch. Cheers, Ken looks ok to me A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: automated stack dumps broken, just output winedbg usage message now?
Le 26/06/2010 01:58, Dan Kegel a écrit : Is anybody else seeing winedbg fail to generate stack dumps? I'm seeing wine: Unhandled page fault on read access to 0x at address 0xb736bd68 (thread 0009), starting debugger... Usage: winedbg [ [ --gdb ] [ prog-name [ prog-args ] |num | file.mdmp | --help ] on a lot of apps when they crash. Could be me, but I figured I'd ask. This is with wine-1.2-rc3. maybe your AeDebug registry entry is broken (in system.reg) it should read (for a standard install): [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 1274602108 Auto=1 Debugger=winedbg --auto %ld %ld or (if you want to still use the debugger when a crash happens) [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 1274602108 Auto=1 Debugger=winedbg %ld %ld A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: ntdll: fix race in NtRead/WriteFile
why not simply setting send_completion to cvalue instead of TRUE, and remove the now unneeded test to cvalue ? - send_completion = TRUE; + send_completion = cvalue != 0; - if (send_completion cvalue) + if (send_completion) A+ 2010/6/21 Andrey Turkin andrey.tur...@gmail.com Long overdue patch to fix bug 11188 - make sure to send i/o completions after all interactions with i/o status block are performed. --- dlls/ntdll/file.c | 24 1 files changed, 20 insertions(+), 4 deletions(-) -- -- Eric Pouech
Re: gcc64 float bug
Le 26/04/2010 19:32, André Hentschel a écrit : Am 25.04.2010 18:52, schrieb Maarten Lankhorst: I'm getting a lot of fixmes about DW_CFA_remember_state/DW_CFA_restore_state not being implemented. Alexandre added support for those items in dwarf unwinding code in ntdll/signal_x86_64.c, but it still requires to be done in dbghelp/dwarf.c. Since the code in the later is heavily derivated from the former, it shouldn't be that hard A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
