_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)
t; +if (loc->dwNetworkVolTableOfs &&
> (loc->dwNetworkVolTableOfsdwTotalSize))
>
me wonders if
if (loc->dwNetworkVolTableOfs && (loc->dwNetworkVolTableOfs +
sizeof(NETWORK_VOLUME_INFO)dwTotalSize))
wouldn't be better
(same also would apply for test in old code above for dwVolTableOfs
--
--
Eric Pouech
Le 10/05/2010 12:06, Alexandre Julliard a écrit :
Eric Pouech writes:
Scenario I (aka Client side)
Create simple wineserver objects (ie not linked to wineconsole) for
bare console handles. All the management would be done in kernel32, by
distinguishing bare
the job control integration, as wineconsole would
gain control of the unix terminal, and hence convert properly the
unix events to the windows one.
I'd rather favor ScII, but the differences are not that big, so your
comments are welcome.
--
Eric Pouech
"The problem with designing s
d with current git (except if gcc really optimizes
things out, but wine now behaves as gcc, so you should be way less
hindered by debugging with -O2 as you were)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
p;traverse);
this is wrong: dwarf_parse family set makes the pointer in the cxt
advance by the size of the object which is being parse
and actually, the correct fix would be to make use of those variables
(like checking if the version is a known one), instead of throwing
things away
() would be to check the gcc version before
trying to use __attribute__().
does the attached patch works better ? (I tried your suggestion starting
at gcc 3.0)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete
e use winegcc for linking either 32bit or
64bit execs (with the --sysroot switch)
not use what you propose will help... it'll prevent an error later on in
gcc (or ld), but if winegcc is passed directories with wrong libraries,
it should, IMO, fail and not try to find the right lib
A+
--
Eric P
bg_vprintf which doesn't exist)
does the attached patch work in your configuration ?
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
diff --git a/programs/winedbg/db_disasm64.c b/pro
joerg-cyril.hoe...@t-systems.com a écrit :
Hi,
Eric Pouech wrote:
this patch is ugly as hell...
Please qualify. To me,
- data[3] = (DWORD_PTR)dev;
+ parms.open.lpstrElementName = dev;
looks more robust than before:
- no magic offsets,
- no casts that may silence
joerg-cyril.hoe...@t-systems.com a écrit :
Hi,
Eric Pouech wrote:
did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ?
It's good you asked. Upon closer inspection, MCI_Sysinfo appears to
behave differently. I'd say it's even a bug
joerg-cyril.hoe...@t-systems.com a écrit :
Hi,
Eric Pouech wrote:
did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ?
Which ones do you have in mind? There are tests involving MCI_ALL_DEVICE_ID
that pass on both win9x and later (also in patch #5). I wrote a few
m
n the Sysinfo patch from earlier today.
Regards,
Jörg Höhle
this patch is ugly as hell... and it still believe we can do the MCI
parser without knowing about MCI structures internals
A+
--
Eric Pouech
"The pr
not in
generic 32bit code
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
Dmitry Timoshkov a écrit :
Eric Pouech wrote:
hmm sounds like most of the code we have in not in sync
[eric:~/work/wine-git debug64|(none)]$ grep TRACE dlls/*/*.c | grep
"%[0-9]*d" | wc -l
8767
[eric:~/work/wine-git debug64|(none)]$ grep TRACE dlls/*/*.c | grep
"%[0-9]*x
/dd743409%28VS.85%29.aspx
yet I refuse to believe it. I believe that all the MCI_XYZ_PARMS
structures are consistent, so that a generic MCI string command parser
is possible. That requires regular types.
Eric Pouech wrote:
http://www.winehq.org/pipermail/wine-devel/2010-February/081660.html
in
is expected as format for integral values
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
Dmitry Timoshkov a écrit :
Eric Pouech wrote:
Can I ask again, why to jump through the hoops if all required information
is already there in appropriate and ready to use/easy to understand format?
because others users want information in decimal, as any other debugger
does
Dmitry Timoshkov a écrit :
Eric Pouech wrote:
bt /x will do what you want.
How will it help with all those backtraces generated and sent by users
to bugzilla? Or those intermittent crashes which are very hard to reproduce?
Is there any reason to spend any time again if all
ready to use/easy to understand format?
if it's information sent by user (in any form), you can always write a
small script to do the job
(and also extend, message number, styles...)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
Alexandre Julliard a écrit :
Eric Pouech writes:
- now exporting the file mapping facility to the debug info loader which need it
- allow to mark a section as to be kept (after debug info loading has been done)
This breaks the non-ELF builds.
where does it break ? about
nyway.
There's ProcessDebugObjectHandle, but it's not clear to me what kind
of handle that actually returns. It's not a process handle at least.
ProcessDebugPort would be preferred (any non zero value would do)
A+
--
Eric Pouech
"The problem with designing something c
nd strings & pointers as DWORD_PTR
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
course
real fix would be (as gdb does in some cases) to disassembly the first
bytes of the functions to guess the prolog size
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
we are.
also ensure that the difference in behavior does come from the OS
version, not the driver (or soundcards) from different boxes
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
André Hentschel a écrit :
Eric Pouech schrieb:
André Hentschel a écrit :
Hi,
I made a patch to merge code from ntdll/signal_x86_64.c to
dbghelp/dwarf.c
The operator DW_OP_deref_size needs to read different sizes of
variables from memory into a fixed size variable.
Now i am not sure if
k] = *(DWORD*)&deref; break;
case 8: stack[++stk] = *(DWORD64*)&deref; break;
}
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
André Hentschel a écrit :
Eric Pouech schrieb:
André Hentschel a écrit :
thanks Eric Pouech for the reviews
---
dlls/dbghelp/dwarf.c | 229
+-
dlls/dbghelp/dwarf.h | 15
2 files changed, 204 insertions(+), 40 deletions(-)
diff
André Hentschel a écrit :
thanks Eric Pouech for the reviews
---
dlls/dbghelp/dwarf.c | 229 +-
dlls/dbghelp/dwarf.h | 15
2 files changed, 204 insertions(+), 40 deletions(-)
diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c
index
ke
filename completion on tab)
so I'd better like an approach where you decide, command by command,
which input strings you send to cmd and how to interpret the final
result out of the shell. the file approach you're currently using could
be of course implemented on top of this f
for most of the cases no, as it'll mean you won't get any debug
information for the built-in modules
so I don't think it's useful (except for testing dbghelp itself, but you
don't need to add it to winetricks for that)
A+
--
Eric Pouech
"The problem with desi
André Hentschel a écrit :
Eric Pouech schrieb:
André Hentschel a écrit :
-
+if (*sym->current == 'A') sym->current++;
I don't understand how this would be necessary?
Are you sure it's needed ?
A+
There is also the possibility "
André Hentschel a écrit :
-
+if (*sym->current == 'A') sym->current++;
I don't understand how this would be necessary?
Are you sure it's needed ?
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
y command (as a way to split in small patches)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
What about redirecting io pipes and use CreateProcess ?
msdn has some examples :
http://msdn.microsoft.com/en-us/library/ms682499%28VS.85%29.aspx
that's what test_cl.h does...
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
Dan Kegel a écrit :
On Fri, Dec 18, 2009 at 11:50 PM, Eric Pouech wrote:
If you want to control more closely commands vs output you can toy with
http://github.com/ericZp/wdtp/blob/master/test_cl.h
I would have thought that overkill for a batch mode program like cmd,
but it appears to
ood, using autohotkey pretty easily.
If you want to control more closely commands vs output you can toy with
http://github.com/ericZp/wdtp/blob/master/test_cl.h
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
to be usable command by command (ie from first
word, to trigger either the old parser or the yacc one, or something
like that)
- when all commands are done, then switch to the global parser mode
I don't think writing the grammar itself will be very complicated, but
wiring all the code to t
Jason Green a écrit :
I don't think it's a good idea to change the exception structure passed
by the caller to the minidump creation
it's better to hard wire the optimization in dump_exception_info
A+
--
Eric Pouech
"The problem with designing something comple
Alexandre Julliard a écrit :
Eric Pouech writes:
Alexandre Julliard a écrit :
Module: wine
Branch: master
Commit: dcec342b50524562844f64d43d423ed2c83c1f97
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=dcec342b50524562844f64d43d423ed2c83c1f97
Author: Alexandre Julliard
code is unmaintainable as it is
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
Alexandre Julliard a écrit :
Eric Pouech writes:
diff --git a/programs/winedbg/dbg.y b/programs/winedbg/dbg.y
index 855407f..7ed6307 100644
--- a/programs/winedbg/dbg.y
+++ b/programs/winedbg/dbg.y
@@ -281,9 +281,9 @@ info_command:
| tINFO tCLASS { info_win32_class(NULL
thunking mechanism for 16-bit edit word break procedures.
Alexandre,
shouldn't the thunk be released in EDIT_WM_NCDestroy upon EDITSTATE
destruction ?
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot.
Alexandre Julliard a écrit :
Eric Pouech writes:
diff --git a/server/debugger.c b/server/debugger.c
index 795a24a..4458a3b 100644
--- a/server/debugger.c
+++ b/server/debugger.c
@@ -677,6 +677,8 @@ DECL_HANDLER(get_exception_status)
if ((event = (struct debug_event *)get_handle_obj
extension)
what's zeroed out is N, whereas you should "repaint" GN into ZG (zero of
size(N), Guard)
which may also explain lots of errors when running the tool
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
Paul Vriens a écrit :
On 11/15/2009 10:07 PM, Eric Pouech wrote:
(fix for #20681)
Hi Eric,
This new test fails on all 32bit systems:
http://test.winehq.org/data/tests/msvcrt:cpp.html
The only box where there are no failures is a 64bit one, but no tests
are actually run there ;)
Could
ation (which means you must force MCI_NOTIFY flag with this
window handle when sending a MCI command down to a driver)
I wonder how native does when no message loop exists in the application
(should be tested) (maybe peek for the notif message upon entrance of
some of the MCI funcs ?)
A+
--
Eric P
be hard to understand the difference between the two
above mentionned thread objects
so, finding another solution might be preferable
what are the thread's missing information you were thinking of ?
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
if it
launched the debuggee itself).
Signed-off-by: Paul Bolle
---
Would it be better to add a new member to gdbctx instead of using a
separate variable (qAttached_reply)?
yes, inclusion in gdbctx is preferred (and storage should rather be an
integer rather than a string pointer)
A+
--
Eric
ne, causing subtle bugs).
What do you think?
BTW, please don't change mciwave now as I still have many patches in the queue.
I'm lagging answering my email
yes, actually, only one thread should be running in background, so what
you suggest sounds fine
A+
--
Eric Pouech
"
fly the needed file)
we already test some .exe this way in winetest
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
ulaw / how are the msacm/gsm711/gsm722/gsm602 tested?
Does anybody know whether ULAW works in Wine? (Any app that uses it outside of
MCI?)
Thanks,
Jörg Höhle
IIRC, I never tested µ-law wave file, so it may well be that the ACM
converter is broken
A+
--
Eric Pouech
"The problem with
Alexandre Julliard a écrit :
Eric Pouech writes:
@@ -1566,7 +1554,41 @@ UINT WINAPI mciLoadCommandResource(HINSTANCE hInst,
LPCWSTR resNameW, UINT type)
if (!(hRsrc = FindResourceW(hInst, resNameW, (LPWSTR)RT_RCDATA))) {
WARN("No command table found in resou
so globally, the functions must be multi-thread safe
and reentrancy requires some testing
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
pper (for 16 and
32 versions of it)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
André Hentschel a écrit :
Eric Pouech schrieb:
Hi André
a couple of comments to your patch
always welcome!
IMO, we should also test that cbReserved2 is >= sizeof(unsigned)
otherwise we'd be in trouble
maybe you had something like that patch in mind:
http://www.wi
l32
+IMPORTS = kernel32 user32
you should do it without user32. instead of doing this
+while (MsgWaitForMultipleObjects( 1, &proc.hProcess, FALSE, INFINITE,
QS_ALLINPUT ) != 0)
+{
+while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) DispatchMessageA(&msg);
+}
you
>
> You can't simply use long here, you need to handle the difference in the
> size of long between Win32 and Unix.
>
> but that's what we currently do !
A+
--
Eric Pouech
+static BOOL HaveDefaultMailClient()
this should be
+static BOOL HaveDefaultMailClient(void)
A+
--
Eric Pouech
before this patch gets ready for
submission
time to stop for tonight, more on this tomorrow
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
Juan Lang a écrit :
Uses %u rather than %d, based on Henri's feedback.
--Juan
Hi Juan
don't you miss a break statement (or a more likely a return 0) at the
end of the block ?
A+
--
Eric Pouech
"T
> break your_func_in_dri_driver
Wine-dbg> cont
TIA
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
;
-mwi.sr_color = mwi.sr_color = 0xFF;
+mwi.sr_color = 0xFF;
}
return &mwi;
}
fix is wrong
the second should be nr_color instead of sr_color (hence the "double"
assignment)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is t
havior) we cannot (yet) in winedbg
decide to filter out some exceptions and some other ones
however, this may work: try the following commands (before run)
set $BreakOnFirstChance=0
run
and see what gives
A+
--
Eric Pouech
"The problem with designing something completely foolproof is t
necessary to pass the information to winedbg, everything's
needed is accessible from winedbg
see tgt_active.c / dbg_handle_exception
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
while updating my git tree, I ran (actually not finished downloading)
this pack:
Resuming fetch of pack 119463f192a563f17ac18ff9b717fbe57199eed7 at
byte 95266539
which size looks quite enormous to me...
any idea of what's going on ?
A+
--
Eric Pouech
"The problem with designing
tand)
the correct short term fix is to handle the loc_error case in
dwarf2_parse_variable (for the DW_AT_location case) by simply doing nothing
the correct long term fix is to implement TLS based variable addressing
in the parser
A+
--
Eric Pouech
"The problem with designing something comple
2009/1/15 Francois Gouget
> On Wed, 14 Jan 2009, Eric Pouech wrote:
>
> > Francois Gouget a écrit :
> > > Hi,
> > >
> > > I have noticed that expr_alloc_uconstant() is unused in winedbg.
> > > Is that normal?
> > >
> >
> > th
handle possibly unsigned:s from
0x8000 up to 0xf (which current code doesn't)
the proper fix would be to fix the lexer to return both signed and
unsigned integers
for example:
WineDbg> p 0x8000
-2147483648
while it should be
2147483648
A+
--
Eric Pouech
"The prob
committers 211 in year: 2005
Number of committers 197 in year: 2006
Number of committers 217 in year: 2007
Number of committers 234 in year: 2008
of course, this doesn't take into account the different names used by
the same person (ie there is for example a "frangois gouget" in th
Francois Gouget a écrit :
> On Sat, 13 Dec 2008, Eric Pouech wrote:
> [...]
>
>>> 1) #ifdef-out regexp support if regex.h is missing? Maybe with an
>>> autoconf check for regcomp()?
>>> 2) Add some reg*() stubs that do nothing if regex.h & co are
e a reason to clutter wine's code with that
*** new option *** 5) use a regex lib for mingw... that work(ed) just fine
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=73286&release_id=140957
we could be a bit more verbose in mingw configuration for this case
A+
--
Eri
n tests, that's the reason I run them
> several times a day after applying patches. The conformance aspect is of
> course important too, but it's not their main use, as demonstrated by
> the number of failures and todos we currently have. So I'll continue to
> call them regr
.c
> 1378
>
>
> Uninitialised value was created by a stack allocation
>
>
> programs/wineconsole/wineconsole.exe.so
> WCUSER_GenerateMouseInputRecord
> programs/wineconsole
> user.c
> 1066
>
>
>
>
>
>
>
>
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
nce if they're upgrading
> from an ancient copy of the software. Under Wine, I need to either
> skip the full-disk search, or warn the user that it may take several
> hours.
>
> --
> Mark
>
>
>
>
>
--
--
Eric Pouech
Dmitry Timoshkov a écrit :
> From: "Eric Pouech" <[EMAIL PROTECTED]> wrote:
>
>
>> +#include
>>
> ...
>
>> +if (!ch || !isalpha(ch)) break;
>>
>
> Since that's apparently a Windows encoding should
; - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. Markus Hitter
> http://www.jump-ing.de/
>
>
>
>
>
>
>
>
>
in short:
- in winedbg, yes but .pdb should be accessible through the
_NT_SYMBOL_PATH environment variable
- under gdb: no, unless you use the win
& d ;-)
unfortunately, http://www.winehq.org/site/docs/winedev-guide/dbg-others
isn't fully uptodate
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
---
>
>
looks a correct fix to me (moving both lines)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
Alexander Nicolaysen Sørnes a écrit :
> På Onsdag 20 august 2008 , 19:30:44 skrev Eric Pouech:
>
>> Alexandre Julliard a écrit :
>>
>>> Module: wine
>>> Branch: master
>>> Commit: 5cb8bccf462790338677dac3bfb394df8f4da020
>>> URL:
todo_wine
> +ok(ret, "CryptMsgGetParam failed: %08x\n", GetLastError());
> +if (ret)
> +buf = CryptMemAlloc(size);
> +else
> +buf = NULL;
> +if (buf)
> + {
> +CMSG_CMS_SIGNER_INFO signer = { 0 };
> +
> +
Proc(HWND hWnd, UINT message, WPARAM
> wParam, LPARAM lParam)
> case ID_REGISTRY_DISCONNECTNETWORKREGISTRY:
> break;
> case ID_REGISTRY_PRINT:
> -PrintRegistryHive(hWnd, _T(""));
> +{
> +const WCHAR empty = 0;
> +PrintR
o have the Linux (or Unix) driver handle several
opening including the mixing of the two streams
if the driver doesn't provide this flexibility, I don't see a point of
implementing it in Wine
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to
xisting function.
> 1 or 2 patches to glue it all together.
>
>
duplicating a lot of functions for A/W compatibility just shows that the
internals of regedit should be moved to unicode first
then your patch will be relatively straightforward
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
Andrew Talbot a écrit :
> Eric Pouech wrote:
>
>
>> looks like a bit strange to me that you get a null typename here
>> can you send me the DLL/.so file on which you get the seg fault
>> A+
>>
>>
>
> No known segfaults; I'm just doing s
> -TRACE("Adding (%ld,%ld) %s\n", filenr1, subnr1, typename);
> +TRACE("Adding (%ld,%ld) %s\n", filenr1, subnr1, typename ? typename :
> "(null)");
>
> return 0;
> }
>
>
>
>
>
looks like a bit strange to me that you get a n
ng long long ptr ptr)
>
should be:
@ stdcall SymEnumerateSymbols64(long double ptr ptr)
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
t: drop
every bug fixes that come after a functional change in the same area of
code), or do you plan to handle yourself the task of retrofit ?
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
Jon Griffiths a écrit :
> Hi,
>
> Subject says it all.
>
>
+dbg_printf("%s", val_int ? "true" : "false");
what about the simpler:
+dbg_printf(val_int ? "true" : "false");
A+
--
Eric Pouech
"The pro
mment: I'm only concerned with
having the best fix in wine (who ever wrote it)
so what's your idea about the fix ?
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
are cases where it doesn't, which is why I added
> this. It's better to have two backtraces than none.
>
>
can you reproduce those cases ? it may be even better to fix those cases
instead of having two backtraces
A+
--
Eric Pouech
"The problem with designing someth
> I'm using same version.
>
> What graphics card, btw?
ATI Radeon HD 2600 XT
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
ne's code growth :-)
>
>
>
>
>
I used to compiled it over 30minutes...
now I barely wait... 6mn26s
make -j5, Q6600 @ 2.4GHz
gcc version also matters (4.2.3 for me)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
Vitaliy Margolen a écrit :
> Eric Pouech wrote:
>
>> @@ -1437,7 +1437,7 @@ static void WCMD_output_asis_len(const WCHAR *message,
>> int len, HANDLE device) {
>> }
>>
>> /* Convert to OEM, then output */
>> -convertedChar
tead of
the band aid your patch is providing
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
, spath, NULL,
> MAX_PATH, path, NULL);
>
actually no
the code intends to find the first occurence of / or \
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
e other items:
- you never handle errors in return from server calls
- where do the 2 (resp 3) factors come from ?
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
processes in the system
'info thread' gives you all the pid:s and tid:s of the running processes
and threads in the system
as of today, you cannot "switch" to another thread
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
>
>
the first one is actually bogus, I'll send a corrected test
however, the second seems ok (except some space difference)
can you post the failing test information ?
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
old .hlp files
The new rendering is turned on by setting the env variable
WINHELP_RICHEDIT to 1
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
the ingenuity of a complete idiot." (Douglas Adams)
101 - 200 of 891 matches
Mail list logo
