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?
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/win
- Get Eclipse 3.7.2 CDT
- Import existing code as Makefile (a wine component or a standalone
- winelib program)
- Check "Automate discovery" in project properties/C/C++ Build/Discovery
- Create a standart C/C++ Application debug configuration
- Set *.exe.so as application
- Set winedbg-eclipse as G
> 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 su
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-start
> Start ddd
> In ddd, use the 'Open File' or 'Open Program' to point to the Wine executable
> (which is either
Hi list. Currently SendInput() works only with wine windows. I need to
send keypresses to all windows, so I created a winelib dll that uses
XTestFakeKeyEvent. I call this function from a wine process, but all
my fake key presses wait for the process to exit.
What is the reason?
Hi list. I suffer from this bug: http://bugs.winehq.org/show_bug.cgi?id=27014
In wine sources there're not so many places where exec(3) family is
used. In some places SIGCHLD and SIGPIPE are restored to default
before calling exec(), in others they aren't. What's the difference?
Can anyone explain
A typical scenario:
- download a file with uTorrent
- select "Open containing folder"
- ???
- use a native program to work with the downloaded file
I think, it would be convenient to add a button to start a terminal or
do "xdg-open ."
When you install a program, some desktop files are put here:
~/.local/share/applications/wine/
~/Desktop/
[Desktop Entry]
Name=Microsoft Office Access 2003
Exec=env WINEPREFIX="/home/leniviy/.wine" wine ...
I have 2 wine instances: official in /usr and patched in
/opt/wine-csshack . Because
In both 1.3.8 and git winedbg --gdb or plain gdb catches several
segfaults, but if I ignore them, the program works.
$ CC="ccache gcc" ./configure CFLAGS="-g -O0"
make
./wine winedbg.exe --gdb notepad
Wine-gdb> cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x7e942cf4 in c
M> VM StatusNumber of test failures
M> WINEBUILDcompleted
M> W98SEcompleted 0
M> WNT4WSSP6completed 0
M> W2KPROSP4completed 0
M> WXPPROSP3completed 0
M> W2K3R2SESP2 completed 0
M> WVISTAADMco
TC> In that case you should check if you have prelink installed and
TC> then configure and build wine.
Kinda works. kernel32 and user32 seem to be on their places.
I Wonder why our package maintainers didn't mark prelink as
makedepends. Maybe it's not 100% reliable? For example if one of the
wine'
>> int main() {
>> HMODULE hKernel32 = GetModuleHandle("kernel32.dll");
>> printf("0x%8x\n", hKernel32);
>> }
>>
>> [...@il winetest]$ wine a.exe
>> 0x7edf
>> [...@il winetest]$ wine a.exe
>> 0x7edf
>> [...@il winetest]$ wine a.exe
>> 0x7ede
TC> Is this on Linux?
yes
--
The struct in question is CSFV defined in shlobh.h. If I try to
compile shell32_test for x64 using headers from windows 2008 SDK, I
get assertion failure here:
http://source.winehq.org/source/dlls/shell32/tests/generated.c?v=wine-1.2-rc5#L1395
Is it normal for wine to have different structure pack
_
PV> Hi Ilya,
PV> In your last email on wine-devel about this subject you mentioned adding
PV> some extra tests. There was at least some communication with you and the
PV> author of that piece you are now removing. The reason for that piece was
PV> shown in a code-snippet he gave and adding test
PV> The only thing I'm wondering is why this big piece was added in the
PV> first place (2004) but that in itself is of course no guarantee it was
PV> needed.
PV> Is it possible to create more tests or is everything possible already
PV> catered for by that one test?
Add a new verb that has '%*' i
Looks like after this commit:
http://source.winehq.org/git/wine.git/?a=commit;h=6164ce2d820546ae5b26eb504bc108091c5679ea
the command
./tools/winapi/msvcmaker --no-wine
silently fails: only 'winetest.dsp' created
Hi! Sorry for being annoying, will you accept my patch?
http://www.winehq.org/pipermail/wine-patches/2010-March/086009.html
--
PV> If this is no longer a todo_wine you should change the filename_tests
PV> struct:
You're right.
Do you have any clue why this block of code was added to
SHELL_execute() ?
There's a block of code in dlls/shell32/shlexec.c
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/shell32/shlexec.c;h=a81cada91fed264816a0946c06e83a00b7fb6484;hb=HEAD#l1681
It specially handles lpFile with '"' or containing spaces. Does anyone
know a real situation when you need this handling
Any news on this topic?
Hi. Is it possible to make a custom dll that wraps some native linux
API? Will a newer version of Wine be able to load a fake dll built for
older release?
Is it necessary to create a new directory under dlls/ and update
configure scripts? Or I can use Wine's Makefile to build in a separate
directo
PV> On 03/08/2010 05:42 PM, Juan Lang wrote:
>> Hi Ilya,
>> I like this one rather better, thanks. Especially the use of broken()
>> makes it clearer what's happening.
>>
>> I think you could tidy it up just a little more:
>>
>>> +expected = 33; sprintf(fileA, testfile, tmpdir);
>>> +rc=sh
>> JL> Also, those TEST_LPFILE_PARSED_OK macros are ugly, and hard to fix if
>> JL> one place has a certain behavior, while another has different
>> JL> behavior. Just use ok directly wherever you're using the macro.
>> Not convinced. What you say is good for reading, but not editing.
>> If som
y in one place, he can jast as simple
copy-paste the definition and edit it.
In any case, it's a free country (c).From 55dfdc06394130ca5c6ddac8d217e231f7501e44 Mon Sep 17 00:00:00 2001
From: Ilya Basin
Date: Thu, 4 Mar 2010 21:48:58 +0300
Subject: shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile
[try
PV> On 03/04/2010 10:56 AM, Ilya Basin wrote:
>> Hello. I can see you ran my tests on a test bot and they don't fail.
>> Thanks. Why don't you put the patch into git? I'm willing to fix the
>> code of the dll itself after the tests are there.
>>
PV> I
Hello. I can see you ran my tests on a test bot and they don't fail.
Thanks. Why don't you put the patch into git? I'm willing to fix the
code of the dll itself after the tests are there.
PV> On 02/17/2010 09:51 AM, Ilya Basin wrote:
>> Hi! Please comment on "try 2" of the patch. Will you accept it?
>> IB> +/* ensure tmpdir is in %TEMP%: GetTempPath() can succeed even if
>> TEMP is undefined */
>> IB> +SetEnvironmentVariableA(&
Hi! Please comment on "try 2" of the patch. Will you accept it?
IB> Hi! This should expose this bug:
IB> http://bugs.winehq.org/show_bug.cgi?id=19385 ( the 'wine start'
IB> launcher does not open MS Office documents that have spaces in their
IB> path ). Although the title is misleading, many other
Thanks for review. Not sending to wine-patches this time. New patch is
in the bottom. What's better, to attach a generated patch or to use it
as a message body?
PV> On 02/11/2010 03:37 PM, Ilya Basin wrote:
>> Hi! This should expose this bug:
>> http://bugs.winehq.org/show_bu
31 matches
Mail list logo
