Hi,
In a dynamically linked in library (not dlload) if I do
@SomeProcInSharedObject is it giving me the address of the code in
memory or something else?
For instance I tried to overwrite a proc in gtk like so:
Orig_addr := PtrUInt(@gtk_widget_get_name);
New_addr := PtrUInt(@glue_gtk_widget_get_n
Op Tue, 6 May 2008, schreef Jonas Maebe:
On 06 May 2008, at 15:02, [EMAIL PROTECTED] wrote:
Why on Win64 on AMD64 is Extended type 64bit same as double and on Win32,
Linux32 and
Linux64 is 80bit.
Because the original win64 releases did not support the use of the 80x87
floating point uni
On Tue, May 06, 2008 at 03:02:19PM +0200, [EMAIL PROTECTED] wrote:
> Hi.
>
> Why on Win64 on AMD64 is Extended type 64bit same as double and on Win32,
> Linux32 and
> Linux64 is 80bit. It breaks for example this construction:
>
> procedure Swap(var X, Y: Double); overload;
> procedure Swap(var X
On 06 May 2008, at 15:02, [EMAIL PROTECTED] wrote:
Why on Win64 on AMD64 is Extended type 64bit same as double and on
Win32, Linux32 and
Linux64 is 80bit.
Because the original win64 releases did not support the use of the
80x87 floating point unit, and it's still considered to be deprecat
Hi.
Why on Win64 on AMD64 is Extended type 64bit same as double and on Win32,
Linux32 and
Linux64 is 80bit. It breaks for example this construction:
procedure Swap(var X, Y: Double); overload;
procedure Swap(var X, Y: Extended); overload;
(I know that extended type is defined as float with the
On 06 May 2008, at 11:10, [EMAIL PROTECTED] wrote:
sysstr.inc r10846 does not include my patch, which solves problem
when both strings
are empty and differs after null character. Then I'am sending it
again merged against trunk.
Just a small note: this routine is only used on Dos, OS/2 and
Hi.
sysstr.inc r10846 does not include my patch, which solves problem when both
strings
are empty and differs after null character. Then I'am sending it again merged
against trunk.
Here is testcase:
program comp;
uses
SysUtils;
var
a, b: array[0..1] of char;
begin
a[0] := #0; a[1] := #1
I have tried both of them (LOCK_SH and LOCK_EX). But the result was the
same.
ik wrote:
You should use LOCK_EX instead (exclusive lock rather then shared lock).
>From the man file (man 2 flock):
LOCK_SH Place a shared lock. More than one process
may hold a shared lock for a gi
You should use LOCK_EX instead (exclusive lock rather then shared lock).
>From the man file (man 2 flock):
LOCK_SH Place a shared lock. More than one process
may hold a shared lock for a given file at a given time.
LOCK_EX Place an exclusive lock. Only one proces
