On March 13, 2003 02:29 am, Sylvain Petreolle wrote:
Not true, as it puts the name of the function being traced.
Of course, silly me. Yeah, come to think of it, the DPRINTF
macro is used to build such strings, together with the
TRACE_ON macro. But regardless, my original objection
against the
Sylvain Petreolle wrote:
It does, see the nice(1), renice (8) commands and get/setpriority(2).
would work. But Linux doesn't allow a non-root process to increase
its scheduling priority (and of course people shouldn't run Wine as
root), so it mostly seemed to just be an exercise in
tor, 2003-03-13 kl. 08:38 skrev Sylvain Petreolle:
It does, see the nice(1), renice (8) commands and get/setpriority(2).
Yes, they all support what I'm saying: a non-root process cannot
increase its scheduling priority (in the common meaning of priority,
not the inversed sense that renice and
What information could be usefull to debug a segfault in
RtlTryEnterCriticalSection ?
Since March beginning I have segfaults into programs that used to run
before.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 8925)]
0x400ba904 in RtlTryEnterCriticalSection
Hi,
Actually, Wine does not have a scheduler as such (well, it has a
scheduler for 16-bit tasks, but not for 32-bit processes/threads).
Wine threads are just normal Linux tasks created with clone().
The usual Linux scheduling rules should apply ...
Thanks for pointing this out. While digging
Florian Schirmer [EMAIL PROTECTED] writes:
I haven't looked deeper into what has caused this trouble, but i suspect
some sleeping/waiting trouble. The new thread proc (for both the clone and
the CreateThread thread) does nothing except registering an alsa async
callback handler and then
Dimitrie O. Paun [EMAIL PROTECTED] writes:
If we detect that we're appending, we just have to skip
over the class:channel:function preamble (that's trivial,
the preamble ends at the first space (' ')).
This way we can eliminate the DPRINTF macro which is
rarely used, and thus confusing.
Sylvain Petreolle wrote:
What information could be usefull to debug a segfault in
RtlTryEnterCriticalSection ?
Since March beginning I have segfaults into programs that used to run
before.
could you check whether %fs is still a valid value ? (ie the one the
thread got upon startup)
A+
--
Eric
This way we can eliminate the DPRINTF macro which is
rarely used, and thus confusing. Alexandre?
Hence my suggestion to only use MESSAGE and DPRINTF inside dumping
functions that can be elimated with macros. But as far as cosmetics
go, i don't see how TMSG and TMS2 are any more ugly than
On 13 Mar 2003, Alexandre Julliard wrote:
No objection. Something like this should do the trick:
Cool! Can you (pretty) please check it in? :)
--
Dimi.
On Thu, 13 Mar 2003, Jon Griffiths wrote:
Hence my suggestion to only use MESSAGE and DPRINTF inside dumping
functions that can be elimated with macros. But as far as cosmetics
go, i don't see how TMSG and TMS2 are any more ugly than MESSAGE.
Check the code before the patch, its just as
I apologize for the multiple posts that sometimes come from me. I need
to change my email program :)
On Wed, 2003-03-12 at 23:54, Maxime Belleng wrote:
This patch replaces my previous patches.
It fixes the computation of the file dialog box size and the component
placement.
Now WinHex open
Jon Griffiths [EMAIL PROTECTED] writes:
Hence my suggestion to only use MESSAGE and DPRINTF inside dumping
functions that can be elimated with macros. But as far as cosmetics
go, i don't see how TMSG and TMS2 are any more ugly than MESSAGE.
Check the code before the patch, its just as bad...
On 13 Mar 2003, Alexandre Julliard wrote:
output. We could certainly have DPRINTF do nothing when trace messages
are compiled out; but this will require going through all the calls to
make sure we use the right macro in each case.
There are 767 DPRINTFs, and 736 MESSAGEs. I think DPRINTFs
Dimitrie O. Paun [EMAIL PROTECTED] writes:
There are 767 DPRINTFs, and 736 MESSAGEs. I think DPRINTFs should just die,
they are confusing, it's not clear what they output, etc. Your patch is just
perfect, as it does the obvious thing the user expects. I think we can just
turn most of the
Alexandre Julliard wrote:
Dimitrie O. Paun [EMAIL PROTECTED] writes:
There are 767 DPRINTFs, and 736 MESSAGEs. I think DPRINTFs should just die,
they are confusing, it's not clear what they output, etc. Your patch is just
perfect, as it does the obvious thing the user expects. I think we can
Change Log: Replace DPRINTF with TRACE
Files changed: windows/dialog.c
windows/win.c
windows/winpos.c
Files not changed: windows/dce.c
windows/winproc
--
Tony Lambregts
Index: dialog.c
G'day all,
I'm using wine in a small control system to run a gui win32 program.
I had an idea that I could determine what dll's this program used and
only including the wine.dll.so files that were required to run this program.
I started by doing a strings on the .exe file and using that to
Am I wrong, or are you wanting to run a windows program without wine ?
This obviously wont work.
=
Sylvain Petreolle
[EMAIL PROTECTED]
Fight Spam ! EuroCauce: http://www.euro.cauce.org/en/index.html
ICQ #170597259
Don't think you are. Know you are. Morpheus, in Matrix.
Hi folks,
I was just thinking that it would be nice if a we had a simple
naming rule for 16 bit functions:
A function is 16 bit if and only if it's name ends in 16.
This way, we can have more reliable tools for detecting
32-16 bit cross calls (unfortunately, winapi_check fails
in many
Eric Pouech [EMAIL PROTECTED] writes:
(Alexandre, in order to handle correctly the loader_critsect between
ntdll kernel32, what do you suggest ? NT does it thru the
fastpeblock in the PEB, which we don't implement. shall we add to the
PDB in some unused field (which means we do export the
On March 13, 2003 08:52 pm, Tony Lambregts wrote:
Well that sounds like a janitorial project.
Right you are:
http://www.dssd.ca/wine/Wine-Janitorial.html#dprintf
--
Dimi.
On March 13, 2003 05:58 pm, Alexandre Julliard wrote:
I agree most of them can be replaced by TRACE, but not all of them.
There are cases where we want to dump debug output without the
standard header; relay output is the obvious example.
Speaking of which, relay output is not really a debug
Sylvain Petreolle wrote:
Am I wrong, or are you wanting to run a windows program without wine ?
This obviously wont work.
You misunderstand me. What I'm trying to do is see how many wine.dll.so
files I can leave off the flash drive and still have the application
fully functional.
For example,
On Fri, 14 Mar 2003, Brad Campbell wrote:
[...]
Am I missing something, or will this work ?
A better way is to run your application with '--debumsg +loaddll'. This
will generate a log enumerating all the libraries that your application
loads (and also tell you whether it's using the native or
25 matches
Mail list logo
