>> The real problem here is types declared in the windows unit where, as I
>> pointed out previously, LongInt has been confused with BYTE, WORD and
LONGWORD
>> types...
> Can you name examples of that?
A little more information ... I just ran h2pas on a couple of header files
from the SDK... It
In reply to your message of August 30, 2003
>> The real problem here is types declared in the windows unit where, as I
>> pointed out previously, LongInt has been confused with BYTE, WORD and LONGWORD
>> types...
> Can you name examples of that?
A little more information ... I just ran h2pas o
In reply to your message of August 30, 2003
>> The real problem here is types declared in the windows unit where, as I
>> pointed out previously, LongInt has been confused with BYTE, WORD and LONGWORD
>> types...
> Can you name examples of that?
> Most notably about byte's and word's confusion
> The real problem here is types declared in the windows unit where, as I
> pointed out previously, LongInt has been confused with BYTE, WORD and LONGWORD
> types...
Can you name examples of that?
Most notably about byte's and word's confusion (so places where types
have a different size then th
intead they will co-exist in one namespace. However, this is not
implemented in FPC 1.0.x so if you use only FPC 1.0.x there's nothing to
worry (however you should be aware of this if you're writing some
non-testing code, that you might want to compile some day with FPC 1.1 or
higher).
FPC 1.1
In reply to your message of August 30, 2003
> Yes. Identifiers in Windows unit will be hidden by same identifiers in
> WinFix unit.
Ok... I was pretty sure that would work. And as you point out so well I'm
aware that it's stopgap at best.
The real problem here is types declared in the windows u
L D Blake wrote:
> Ok, still messing with this silly problem...
>
> Now the question is about order of declaration in units...
>
> Lets say I wrote a unit "WinFix" with some of these cursed range checking
> problems cleaned up... am I correct in assuming that if I added it to my units
> list lik
Not to be pedantic, but can I request that we as TRUE hackers at least
get the terminology right. The site was a cracked by a cracker.
FPC was created, and is used by a large number of hackers.
Maybe I should just give upsigh.
Ciao
A.J.
On Fri, 2003-08-29 at 12:31, Sigurd Stordal wrote:
>
Ok, still messing with this silly problem...
Now the question is about order of declaration in units...
Lets say I wrote a unit "WinFix" with some of these cursed range checking
problems cleaned up... am I correct in assuming that if I added it to my units
list like this:
Uses
On Fri, 29 Aug 2003, Sigurd Stordal wrote:
> > That's so pathetic. What'd the hacker do anyhow ? And how the heck does
> > a hacker break into a *nix box ? (I assume it is...)
> It's easy. At least if you run an old redhat, or run some of the dangerous
> services.
You really need to be deligent a
Marco van de Voort wrote:
...
> Does somebody know something more about Winapi errorhandling?
...
It works the same way as under libc but instead checking ErrNo you check GetLastError.
Expressing it as clearly as I can: For each WinPAI call you should check the WinAPI
documentation (as with ev
In reply to your message of August 30, 2003
> Something else. But I think you are on the wrong track with HWND.
This is a possibility I've considered. It might be something else entirely...
but it is definately something related to my program...
Another possibility, and one I've tested for, is
In reply to your message of August 30, 2003
> We can discuss principles for hours of course, but that doesn't help you.
> Did you try to change the HWND type from longint to DWORD or Cardinal
> (which is the same) in the windows unit ? If so, does it help ?
I re-declared Hwind to be a longword in
> That's so pathetic. What'd the hacker do anyhow ? And how the heck does
> a hacker break into a *nix box ? (I assume it is...)
It's easy. At least if you run an old redhat, or run some of the dangerous
services.
I remember my machine been hacked into some year ago. The redhat of then just
compl
> In reply to your message of August 29, 2003
>
> > And it has been already a longint for 5 years.
>
> Which pre-dates all of NT4, win2000, XP, 2003 ... Which are true 32 bit
> operating systems.
NT4 is older, I run 2000 and before that its beta's on my work space for 24
hours/a week since earl
> In reply to your message of August 29, 2003
>
> > Yes I think about it. Typed negative on this side (the pascal side). On
> > 2-complements it is the same binary layout, only the interpretation is
> > different. The win32 API sees no difference, since it puts its own typing
> > over it.
>
> No
On Fri, 29 Aug 2003, L D Blake wrote:
> In reply to your message of August 29, 2003
> > Yes I think about it. Typed negative on this side (the pascal side). On
> > 2-complements it is the same binary layout, only the interpretation is
> > different. The win32 API sees no difference, since it pu
In reply to your message of August 29, 2003
> Yes I think about it. Typed negative on this side (the pascal side). On
> 2-complements it is the same binary layout, only the interpretation is
> different. The win32 API sees no difference, since it puts its own typing
> over it.
Not to be sarcasti
In reply to your message of August 29, 2003
> And it has been already a longint for 5 years.
Which pre-dates all of NT4, win2000, XP, 2003 ... Which are true 32 bit
operating systems.
I can't help wondering if the handle is somehow being changed by the type
mismatch giving rise to duplicate han
In reply to your message of August 29, 2003
> Yes I think about it. Typed negative on this side (the pascal side). On
> 2-complements it is the same binary layout, only the interpretation is
> different. The win32 API sees no difference, since it puts its own typing
> over it.
Turn on Pascal's ra
20 matches
Mail list logo
