On Jul 25, 2013, at 2:11 PM, Qian Hong wrote:
> On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases wrote:
>> I think your Valgrind results are telling us that there's a bug in the game
>> where it's using an uninitialized stack variable.
>>
>> There's still a chance that it's something in Wine that'
On Fri, Jul 26, 2013 at 2:52 AM, Ken Thomases wrote:
> I think your Valgrind results are telling us that there's a bug in the game
> where it's using an uninitialized stack variable.
>
> There's still a chance that it's something in Wine that's using the
> uninitialized variable and passing a ga
Hi Qian,
On Jul 25, 2013, at 11:53 AM, Qian Hong wrote:
> On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases wrote:
>> Hmm. You may need to mark the dummy array as volatile to prevent it from
>> being optimized away. Worth trying. You might also increase the size of
>> the array.
>
> You are ri
Hi Ken,
On Thu, Jul 25, 2013 at 2:33 AM, Ken Thomases wrote:
> Hmm. You may need to mark the dummy array as volatile to prevent it from
> being optimized away. Worth trying. You might also increase the size of the
> array.
You are right, thanks! Increasing the size of the array helps, the
m
On Jul 24, 2013, at 12:49 PM, Qian Hong wrote:
> Hi Ken,
>
> On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases wrote:
>> Instead of enabling the trace, try replacing it with something like:
>>
>>char dummy[256];
>>memset(dummy, 0x55, sizeof(dummy));
>>
>> I bet the crash will change from a
Hi Ken,
On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases wrote:
> Instead of enabling the trace, try replacing it with something like:
>
> char dummy[256];
> memset(dummy, 0x55, sizeof(dummy));
>
> I bet the crash will change from a read access to 0x0001 to 0x.
>
Thanks for the
On Sat, Jul 20, 2013 at 2:21 AM, Marcus Meissner wrote:
> Or timing ... Also can you print out refcount there to see if the refcounting
> is good?
Thanks Marcus, yes, I tried replace the TRACE to printf, to my
surprise, the magic disappear.
In other words, if I replace the TRACE in d3d9_AddRef t
Hello,
Thanks everyone's help, sorry for delay, I was blocked by something else.
I've created http://bugs.winehq.org/show_bug.cgi?id=34125 to track
down this bug.
On Fri, Jul 19, 2013 at 10:06 PM, Henri Verbeet wrote:
> Well, it sounds a bit like some form of memory corruption. Sometimes
> WINED
On Jul 19, 2013, at 8:34 AM, Qian Hong wrote:
> I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
>
> +relay,+seh,+tid log show that there are some calls to
> wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
> wined3d.wined3d_mutex_unlock before cras
On Fri, Jul 19, 2013 at 04:06:56PM +0200, Henri Verbeet wrote:
> On 19 July 2013 15:34, Qian Hong wrote:
> > Further tests show that the simplest hack to avoid crashing is
> > replacing line 71 to:
> > FIXME("anything %x\n", 0xdeadbeef);
> >
> > I have no idea what the real fix is, any suggestion
On 19 July 2013 15:34, Qian Hong wrote:
> Further tests show that the simplest hack to avoid crashing is
> replacing line 71 to:
> FIXME("anything %x\n", 0xdeadbeef);
>
> I have no idea what the real fix is, any suggestion what is the next
> step to debug?
>
Well, it sounds a bit like some form of
Hello,
I was debugging on a popular game [1] [2] (9 GB), it crashes on start.
+relay,+seh,+tid log show that there are some calls to
wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map /
wined3d.wined3d_mutex_unlock before crashing, so I turn on +d3d9 trace
to get a new log in details.
To
Nozomi Kodama writes:
> Hello.
>
> I took advantage of this minor patch to clean up and make uniform the
> coding style of this file.
Please don't do that.
--
Alexandre Julliard
julli...@winehq.org
On 15.02.2013 08:20, Nozomi Kodama wrote:
@@ -721,9 +739,10 @@ D3DXMATRIX* WINAPI D3DXMatrixTransformation(D3DXMATRIX
*pout, const D3DXVECTOR3
@@ -797,69 +821,70 @@ D3DXMATRIX* WINAPI D3DXMatrixTransformation2D(D3DXMATRIX
*pout, const D3DXVECTOR
Those two functions need a speed improvement. No
n, please enlighten me.
> Thank You in advance!
>
There are some tricks you can do to limit what executables you turn
debugging on for, or to e.g. dump the output to separate files. You'll
mostly want to look at debug_init() in libs/wine/debug.c. If this is a
simple crash though, perhap
Good day!
Does anyone has any experience on dealing with Steam when debugging a
game which depends on Steam?
I am trying to squash a bug which makes a game crash. I started from
relay logs, but have a bit of a problem - calls from Steam itself
produce a few megabytes worth of relay logs every
What is the proper way to debug wineboot and services.exe in order to find out
what is causing the error outputted by wineserver below?
err:wineboot:start_services_process Couldn't start services.exe: error 1359
wine: failed to update /winearm/winehome with
/winearm/bin/../share/wine/wine.inf:
Actually, to enable attach, I had to make ptrace more permissive:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection
by doing "echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope"
To run it under eclipse I had to choose Traditional Attach to process
instead of DSF.
On
Attach works. Thanks!
So, you didn't try to build wine? Installed wine also works for me.
On Sat, Jul 07, 2012 at 01:25:12PM +0300, John Yani wrote:
> I tried "WINELOADER=./wine winedbg --gdb notepad"
>
> And its output is the same as "./wine winedbg --gdb notepad"
Well, i have a installed wine... but doing this there:
wine winedbg.exe --gdb notepad.exe
0042:0043: create process 'C
Maybe it's because I'm building on chrooted Ubuntu x32 and run on Ubuntu x64?
I tried "WINELOADER=./wine winedbg --gdb notepad"
And its output is the same as "./wine winedbg --gdb notepad"
Unfortunately, it doesn't work:
./wine winedbg --gdb notepad.exe
err:module:LdrInitializeThunk Main exe initialization for
L"C:\\windows\\system32\\notepad.exe" failed, status c022
0023:0024: create process ''/0x1106c0 @0x7ebe233c (0<0>)
fixme:dbghelp:EnumerateLoadedModulesW64 If this happens,
On Sat, Jul 07, 2012 at 01:11:42PM +0300, John Yani wrote:
> Did you mean './wine winedbg --gdb notepad'? Because I can't find winedbg
> binary.
This would be the same. There usually is a "winedbg" wrapper installed
that does the same, but for all purposes its the same thing.
Ciao, Marcus
Did you mean './wine winedbg --gdb notepad'? Because I can't find winedbg
binary.
On Sat, Jul 07, 2012 at 12:17:00AM +0300, John Yani wrote:
> I tried to run wine under gdb and failed. Using multiprocess gdb I
> endup with weird trace:
>
> 0xf7ffd430
> 0x7bc846f9
> 0x7bc8480f
> 0x7bc84855
> 0x7bc42a94
> 0x7bc433b1
> 0x7b8772f7
> 0x7ebab89b
> 0x7b
I tried to run wine under gdb and failed. Using multiprocess gdb I
endup with weird trace:
0xf7ffd430
0x7bc846f9
0x7bc8480f
0x7bc84855
0x7bc42a94
0x7bc433b1
0x7b8772f7
0x7ebab89b
0x7bc80014
0x7bc8005d
Where 0x7** addresses are not co
e big picture is that I'd like to get an IDE such as QtCreator or
KDevelop to work debugging a WINE application. Any way that is possible
would be a good solution for me; it doesn't necessarily have to be through
GDB if there's another way.
Thanks for your help in advance!
-Louis
On 01/18/2012 10:10 PM, Roland Baudin wrote:
You can find the attached complete patch against wine 1.3.35.
Hello Roland,
Please send patches to wine-patches.
Unless you are asking for feedback?
HTH,
Joris
Hi,
I finally solved the menubar issue (menubar not shown in Lightroom 3.x
when Windows version is set to Windows XP or below).
I used a mix of the following patches :
- http://source.winehq.org/patches/data/67089 from Andrew Eikum
(GetMenuBarInfo() partial implementation)
- http://www.win
OK, thanks for your help.
I'll try this when I'll be back to home.
RB
- Mail original -
De: "Frédéric Delanoy"
À: rolan...@free.fr
Cc: "Juan Lang" , wine-devel@winehq.org
Envoyé: Mardi 20 Décembre 2011 12:28:57
Objet: Re: Debugging Wine with Lightroom 3.5
On Tue, Dec 20, 2011 at 10:04, wrote:
>
> Yes, I'm that kind of person (I'm the developer of Xfe and TexMaths) but I've
> seen the +relay logs logs and they are indeed very huge, even for me!
> RB
What you can do to reduce/manage the log size:
1. Launch any application (without logging), e.g. n
Dimanche 18 Décembre 2011 16:15:49
Objet: Re: Debugging Wine with Lightroom 3.5
Hi Roland,
On Sun, Dec 18, 2011 at 6:46 AM, Roland Baudin wrote:
> Yes, I suspected such a mechanism. Now if I understand well I have to find
> which one is the "builtin mechanism" and which one is the "
Hi Roland,
On Sun, Dec 18, 2011 at 6:46 AM, Roland Baudin wrote:
> Yes, I suspected such a mechanism. Now if I understand well I have to find
> which one is the "builtin mechanism" and which one is the "fallback
> mechanism".
> Is there some documentation around about the differences between Vist
Yes, I suspected such a mechanism. Now if I understand well I have to
find which one is the "builtin mechanism" and which one is the "fallback
mechanism".
Is there some documentation around about the differences between Vista
and XP?
Anyway, thanks for your help...
RB
Le 18/12/2011 13:40, Jo
Replying, also including the wine-devel list,
On 12/17/2011 05:15 PM, Roland Baudin wrote:
Hi,
thanks for the answer.
What do you mean by "a different execution path"?
RB
The application might decide to execute different code given the Vista
settings.
It may have a preferred execution path u
It's possible the application is choosing a different execution path,
using Vista-specific features.
This could be an explanation for the differences you are seeing.
HTH,
Joris
ng I suspect the problem is in the user32.dll
and perhaps the DrawMenuBar implementation but I'm not sure...
Any help (at least some clue to start debugging) would be greatly
appreciated.
Thanks,
RB
--
X File Explorer http://roland65.free.fr/xfe
Toutes Choses http://roland65.free.fr/ttc
Doesn't apply here:
$ wget http://source.winehq.org/patches/data/79041
$ git reset --hard origin
$ patch -p1 < 79041
patching file include/Makefile.in
patching file include/cordebug.idl
patch: malformed patch at line 998: --
$ git reset --hard origin
$ git apply 79041
79041:99: trailing whit
alhost:57380" in ddd's command line and it connects. But how do I
>>> attach the source code and so on (I'm use to debugging in Eclipse and
>>> VS)?
>> I'm not sure about that, I never used any graphical debuggers with Wine. But
>> gdb(and winedbg) al
On Fri, Jun 24, 2011 at 3:55 PM, Henri Verbeet wrote:
> On 24 June 2011 15:24, Michael Mc Donnell wrote:
>> I can set a break point at test_convert_point_reps_to_adjacency (my
>> new test) and it stops there. I can also set a break point for
>> ID3DXMeshImpl_ConvertPointRepsToAdjacency but it jus
On 24 June 2011 15:24, Michael Mc Donnell wrote:
> I can set a break point at test_convert_point_reps_to_adjacency (my
> new test) and it stops there. I can also set a break point for
> ID3DXMeshImpl_ConvertPointRepsToAdjacency but it just goes past it.
>
> Here are the commands I used:
> b test_c
gt; attach the source code and so on (I'm use to debugging in Eclipse and
>> VS)?
> I'm not sure about that, I never used any graphical debuggers with Wine. But
> gdb(and winedbg) always found the Wine source, my assumption was that the path
> to it is stored in the binaries
On Friday 24 June 2011 14:44:10 Michael Mc Donnell wrote:
> Now I want to connect my graphical debugger. I enter "target remote
> localhost:57380" in ddd's command line and it connects. But how do I
> attach the source code and so on (I'm use to debugging in Eclipse
what port to connect on. Something like:
target remote localhost:57380
Now I want to connect my graphical debugger. I enter "target remote
localhost:57380" in ddd's command line and it connects. But how do I
attach the source code and so on (I'm use to debugging in Eclipse and
VS)?
On Friday 24 June 2011 11:53:22 Michael Mc Donnell wrote:
> $ ../../../tools/runtest name_of_test
>
> Is there a way to run the test in a debugger, so that I can single
> step through the functions that the test calls?
../../../wine winedbg foo_test.exe.so should work.
signature.asc
Description:
Hi
I'm trying to figure out how to single step through the code. I've
looked at the winedbg and gdb information on winehq, but still can't
figure out what to do. I normally run tests by issuing:
$ ../../../tools/runtest name_of_test
Is there a way to run the test in a debugger, so that I can sin
her point, what about how we handle offscreen buffers? All FBO etc etc?
>
Most of it really does come down to careful debugging / benchmarking,
I'm afraid. There's plenty of speculation, but at some point someone
just has to do the actual work.
> If I remember correctly someone was worki
Hi, let me agree with you... probably there might be one or two fixes
somewhere which will make performance go better, but apparently the idea
is that now, if "early optimization is the root of all evils" was true a
while a go, I guess we're at a place where all the small optimizations
should t
On Sunday 01 May 2011 14:34:53 Emanuele Oriani wrote:
> Indeed, I've written a spinlock with GCC extension and replaced the
> EnterCriticalSection in the x11 drv file.
> Apart that the lock has got to be recursive, so I implemented a quick
> (but incorrect) recursive spinlock for the purpose of run
Indeed, I've written a spinlock with GCC extension and replaced the
EnterCriticalSection in the x11 drv file.
Apart that the lock has got to be recursive, so I implemented a quick
(but incorrect) recursive spinlock for the purpose of running SC2 and
difference was barely negligible.
The biggest
On Saturday 30 April 2011 18:26:04 Emanuele Oriani wrote:
> Hi Stefan,
>
> What do you think about using inline spinlocks (in asm code maybe) to
> implement locks?
> Clearly an optimized spinlock would mean different code for different
> compilers/architectures, but shouldn't it be the best soluti
On Saturday 30 April 2011 17:18:54 Stefan Dösinger wrote:
> 9-11) Distributor / End use choice. Note that some compiler
> flags(especially the framepointer one) can break apps and copy protection
> systems.
Forget about -O3. I can't get any Windows game working with that. Apparently I
am already l
Hi Stefan,
What do you think about using inline spinlocks (in asm code maybe) to
implement locks?
Clearly an optimized spinlock would mean different code for different
compilers/architectures, but shouldn't it be the best solution?
For your reference, once I commented out the GL locks to see St
Hi,
Here's another update.
First I expanded my performance tests at https://84.112.174.163/~git/perftest
a bit. The old tests were renamned to streamsrc_d3d and streamsrc_gl, and I
added another set of tests that just tests the draw overhead without ever
changing any states: drawprim_d3d and dr
Hi,
I spent a few hours debugging wined3d performance today. No, I found no magic
fix for the slowness, just some semi-usable data.
First I wrote a hacky patch to avoid redundant FBO applications. This gave a
tiny, tiny performance increase, see http://www.winehq.org/pipermail/wine-
devel/2011
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).
Registe
ou may have more luck with
gdb. On OSX this sometimes gives more helpful output. But I am afraid you'll
need other debugging techniques like logfiles.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
iQIcBAEBAgAGBQJNsqKRAAoJEN0/YqbEcdMwjHIP+wZc/5gVsQ/a7NpNHu4w0bcm
u7ZB
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 G
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 i
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.
Maarten Lankhorst writes:
> Since warn+debugstr takes user data increase and basically does
> WARN("%s\n", msg); the buffer size is too small, increasing the size
> makes the lord of the rings online launcher print messages to WARN
> without crashing
That's just hiding the bug.
--
Alexandre Ju
= 1.3.10-1.fc14 for package:
> wine-1.3.10-1.fc14.i686
> --> Running transaction check
> ---> Package wine-wow.i686 0:1.3.10-1.fc14 set to be installed
> --> Processing Conflict: wine-1.3.10-1.fc14.x86_64 conflicts wine-wow(x86-32)
> = 1.3.10-1.fc14
> --> Finished D
3.10-1.fc14 set to be installed
--> Processing Conflict: wine-1.3.10-1.fc14.x86_64 conflicts
wine-wow(x86-32) = 1.3.10-1.fc14
--> Finished Dependency Resolution
Error: wine conflicts with wine-wow
To me this suggests that wine.i686 is exclusively for 32bit,
which I'm hesitant use (I'd l
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 co
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 p
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
lto:winehq@urbanec.net]
Sent: Thursday, September 23, 2010 10:05 AM
To: wine-devel@winehq.org
Subject: Re: Debugging 64-bit Wine Apps with winedbg
On 23/09/10 06:51, Tom Grubbe wrote:
> problem seems to be getting any kind of stack trace information from
> the 64-bit winedbg. This used t
t Wine applications is welcome
I would also like to hear any tips for debugging under wine64. I'm
finding that even the minidump files produced by wine64 are not much use
in VS2005 or VS2008. At least the minidumps from wine32 can provide a
little bit of info when loaded into VS2008 debug
Hi,
I'm not a winedbg expert but I think your mis-using it.
As it's your software, you can compile it from source and add debug info.
I know Visual Studio can create .pdb files but I don't know if winedbg
can use it.
Personally, I'm using gcc mingw with -g and that perfectly works.
The easies
Hello, we're the developers of a large 64-bit Windows application that uses
Wine 1.3.0 64-bit on Linux. When testing began we discovered several crashes
inside our windows code on startup and needed to debug them. But the problem
seems to be getting any kind of stack trace information from the
For those of you who have developed 64-bit apps with wine, I'd like to ask what
debugging tools and techniques you found most effective in that environment.
Anyone have good luck with the 64-bit winedbg or remote debugging using Visual
Studio?
Thanks,
Ben Parker
ESRI
2010/8/4 André Hentschel
> Hi,
> what is the best/easiest/fastest way to hack Wine so it does not start
> winedbg and i can debug it with gdb?
> my problem is that my WineARM works so far that it tries to run winedbg and
> uses its own handlers. but i want that not to happen
> of course it crashe
Hi,
what is the best/easiest/fastest way to hack Wine so it does not start winedbg
and i can debug it with gdb?
my problem is that my WineARM works so far that it tries to run winedbg and
uses its own handlers. but i want that not to happen
of course it crashes somewhere and then tries to start w
Eric Pouech wrote:
Peter Urbanec a écrit :
It can't be as simple as updating the value of dbg_curr_thread with
the result of dbg_get_thread(dbg_curr_process, tid) and then calling
GetThreadContext(dbg_curr_thread->handle, &dbg_context), can it?
the changes will need to be larger than that
wi
Am 18.10.2009 um 16:24 schrieb Warren Dumortier:
I don't think it's worth to be tested, because if Xfire doesn't
crash (simply by not interacting with it) games are detected.
However i will try it, who knows! ;)
An easier way to test is probably to disable Xfire In-Game, if you
find out how
Am 18.10.2009 um 15:02 schrieb Warren Dumortier:
Xfire was working until version 1.104, but since then it crashed on
every Wine version, so the Xfire update broke it under Wine.
Here's the problem:
Xfire crashes every time you interact with it's GUI, well most of
the time...
When using the
Xfire was working until version 1.104, but since then it crashed on every
Wine version, so the Xfire update broke it under Wine.
Here's the problem:
Xfire crashes every time you interact with it's GUI, well most of the
time...
When using the keyboard it crashes sometimes, but when using the mouse
> I just would try to use Kdevelop, but i dont know if it will work.
>
Actually KDevelop works. I created a new empty project and Imported the
whole git repository and
I chose to use wine's custom MakeFile and configure files. I'm not able
though to start the debug properly
but I'm working on it.
Alexandros Dermenakis schrieb:
Hi,
I would like some help about which tools to use for editing code, searching
through the source files etc. also, is there a way to import all the source
code in Kdevelop?
thanks
I mostly edit the files with Geany(geany.org), but thats a matter of taste.
On Sun, Aug 9, 2009 at 10:50 PM, Alexandros
Dermenakis wrote:
> Hi,
>
> I would like some help about which tools to use for editing code, searching
> through the source files etc. also, is there a way to import all the source
> code in Kdevelop?
To get the source:
http://wiki.winehq.org/GitWine
f
Hi,
I would like some help about which tools to use for editing code, searching
through the source files etc. also, is there a way to import all the source
code in Kdevelop?
thanks
Hello,
I am trying to make a very special application working with Wine 1.1.20
(Loris, from Ever Ezida, a library management software). Almost
everything is functionnal, but there is a little graphical bug with some
texfields. Also, I would like to know if there are some ways to debug a
GUI, espec
Hello,
I am trying to make a very special application working with Wine 1.1.20
(Loris, from Ever Ezida, a library management software). Almost
everything is functionnal, but there is a little graphical bug with some
texfields. Also, I would like to know if there are some ways to debug a
GUI, espec
Reece Dunn a écrit :
> 2009/5/5 Austin English :
>
>> On Tue, May 5, 2009 at 2:13 AM, Benoit SCHWINDEN
>> wrote:
>>
>>> Hello,
>>>
>>> I am trying to make a very special application working with Wine 1.1.20
>>> (Loris, from Ever Ezida, a library management software). Almost
>>> everything
Austin English a écrit :
> On Tue, May 5, 2009 at 2:13 AM, Benoit SCHWINDEN
> wrote:
>
>> Hello,
>>
>> I am trying to make a very special application working with Wine 1.1.20
>> (Loris, from Ever Ezida, a library management software). Almost
>> everything is functionnal, but there is a little g
2009/5/5 Austin English :
> On Tue, May 5, 2009 at 2:13 AM, Benoit SCHWINDEN
> wrote:
>> Hello,
>>
>> I am trying to make a very special application working with Wine 1.1.20
>> (Loris, from Ever Ezida, a library management software). Almost
>> everything is functionnal, but there is a little graph
On Tue, May 5, 2009 at 2:13 AM, Benoit SCHWINDEN
wrote:
> Hello,
>
> I am trying to make a very special application working with Wine 1.1.20
> (Loris, from Ever Ezida, a library management software). Almost
> everything is functionnal, but there is a little graphical bug with some
> texfields. Als
Hello,
I am trying to make a very special application working with Wine 1.1.20
(Loris, from Ever Ezida, a library management software). Almost
everything is functionnal, but there is a little graphical bug with some
texfields. Also, I would like to know if there are some ways to debug a
GUI, espec
Juan Lang writes:
> +static void dump_element(PCCERT_CONTEXT cert)
> +{
> +LPWSTR name = NULL;
> +DWORD len, i;
> +
> +TRACE_(chain)("%p\n", cert);
> +len = CertGetNameStringW(cert, CERT_NAME_SIMPLE_DISPLAY_TYPE,
> + CERT_NAME_ISSUER_FLAG, NULL, NULL, 0);
> +name = CryptMe
On Mon, Dec 15, 2008 at 1:15 PM, Austin English wrote:
> --
> -Austin
>
Are you adding this because you've been debugging the msi db code?
Knowing the row number that we failed to insert is not helpful. In
most cases, this message is harmless and should be a warn or removed
comp
So Sitting on the airplane I was thinking of additional clarifications
on debugging. Again these are just some ideas...
So lets look at an exception:
What I am talking about when more descriptive is this :
Since we know from other parts where the read is done.. why not dump the
line of code
r:$cwd
(gdb)
** Then, run the app
(gdb) run windows/notepad.exe
Starting program: /usr/local/bin/wine windows/notepad.exe
[Thread debugging using libthread_db enabled]
[New Thread 0xf7c628c0 (LWP 793)]
[New Thread 0xf7c61b90 (LWP 796)]
[Thread 0xf7c61b90 (LWP 796) exited]
[New process 793]
Execut
On Wednesday 10 September 2008 10:44:09 pm Damjan Jovanovic wrote:
> For example applications don't expect to see pointers into the upper
> 1-2 GB of the 4 GB virtual memory address space because on Windows the
> kernel's memory is mapped there. But, ld-linux.so.2 could load
> libraries there, incl
On Wed, Sep 10, 2008 at 8:17 PM, <[EMAIL PROTECTED]> wrote:
> Question :
> Why does wine have to allocate all its memory at startup? re... the issue
> that is causing the ATI drivers to have such
> a fuss why not just allocate as needed? or have the ability (if its not
> there already) to sp
dbghelp supports both linux debug formats (stabs, dwarf) as well as
microsoft's one
so any debugger using dbghelp as it's debug info provide should debug
with all bells & whistles native & builtin applications
I had some success with windbg (with a an 'e' between n & d ;-)
unfortunately, http://
ubject: RE: Debugging Wine thoughts
You can
attach any debugger to a Win32 process running in Wine. This includes Linux
debuggers like gdb, or any graphical frontends, as well as Windows debuggers
like visual studio. If you built wine from source, the Linux debuggers will s
devel@winehq.org
Subject: Debugging Wine thoughts
Dan / All,
I think what the guy was asking on improving winedbg is to have some sort of
visual debugger much like VC/C++ , Eclipse,
Borland C++ or the like... Where you can step through the code (seeing the
whole thing like any visual debugger).
Then
On Sep 8, 2008, at 9:36 PM, Dan Kegel wrote:
> Kevin K wrote:
>> Is winedbg the only method of debugging applications being
>> developed for Windows on Wine?
>>
>> For instance, assume a program developed with Visual Studio
>> in C or C++, and I needed to
1 - 100 of 473 matches
Mail list logo
