RE: [fpc-devel] DLL WIN64: Entry point not found
That's my sql with the error code from firebird.
SELECT simple('tes t !') FROM rdb$database
ISC ERROR CODE:335544343
ISC ERROR MESSAGE:
invalid request BLR at offset 79
function SIMPLE is not defined
module name or entrypoint could not be found
UDF declation is
DECLARE EXTERNAL FUNCTION SIMPLE
CSTRING (254)
RETURNS CSTRING (254)
ENTRY_POINT 'Simple' MODULE_NAME 'SitaUdfLib.dll'
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dimitrios Chr.
Ioannidis
Sent: mercredi 18 juillet 2007 19:06
To: FPC developers' list
Subject: Re: [fpc-devel] DLL WIN64: Entry point not found
O/H Vincent Snijders Ýãñáøå:
> Mark - WBIsoft.COM schreef:
>> I think the calling convention be STDCALL ?
>>
>>
>
> IIRC, that is the same on win64.
Are you sure about this ?
AFAIK, they have opposite order of arguments in stack. In cdecl caller
will clean up stack after the call (raise ESP) while in stdcall this is
job of called function. I see no reason to change this because of
32\64\128 bit architecture of CPU.
Anyway, the calling convention for a Firebird UDF is still cdecl either
for x86_64 or x86_32.
PS: Don't forget to use ib_util_malloc() from ib_util.dll to allocate
memory for the UDF result string declared as FREE_IT.
regards,
--
Dimitrios Chr. Ioannidis
Firebird Project
http://www.firebirdsql.org
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] DLL WIN64: Entry point not found
A host application compiled with fpc don't have this problem.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vincent
Snijders
Sent: mercredi 18 juillet 2007 18:41
To: FPC developers' list
Subject: Re: [fpc-devel] DLL WIN64: Entry point not found
Luc Vigato, Sita Software schreef:
> Here an little test DLL (SitaUdfLib.pas). It also don't work with firebird
> 2.1 64bit version.
How can I test this, without installing firebird?
Do you have another host application?
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
begin 666 TestSitaUDFDLL.pas
M<')O9W)A;2!497-T4VET855$1D1,3#L-"@T*>R1M;V1E(&]B:F9P8WU[)[EMAIL PROTECTED]
M?0T*#0IUR1%3D1)1GU[)$5.1$E&?0T*("!#;&%SCI00VAA'1Ehttp://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Therefore, console is popular as well. I second this! So far I've using FPC to develop server-side application (using PSP/PWU) which has no X installed on the server machine and I only have SSH access to the machine. fpIDE is the best text mode IDE on Linux. -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
> On Wed, 18 Jul 2007, Dani?l Mantione wrote: > > What is bad about such a solution? > > It's not KIS. If you can't have certain keys without being root, well then > you'll have to learn to live with it. IMHO either give up the textmode IDE, or try to support it to the fullest extend. > This is no longer the MS-DOS age when > everything was possible. "everything" being using the standard keyboard type that is around for 15 years. > It's a shortcoming of the platform, and for me > this is the end of the story. The keyboard unit should in no way set up > such a communication channel; if you absolutely want that, you can set > it up for the IDE (I don't use it anyway), but not for the standard keyboard > driver unit. Develop a driver that handles this, and use that in the IDE. (skip this if you hate rants) Why bother with more advanced keyboard at all then? The platform obviously is not fond of simple keyboard systems or unit keyboard would not be several thousand lines. Maybe we should repatch the IDE to a VI mode so we can kill function keys:-) ) > Rather, we should request that they implement a decent keyboard > interface which allows you to detect properly the state of all keys on > the terminal which you are currently using. Definitely. And that was also one of the points I wanted to make when I made the half serious setuid remark. The problem should be propagated back, specially if it is configurable in the kernel. Maybe it will at least make some distro packagers of more desktop distroes aware of the problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
> Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > Under the assumption a setuid root program is the only possible option: > > > > The safest - and in my opinion only correct - way is to write a small > > setuid > > root program which sets the proper TTY stuff, and then executes the IDE as > > the normal user. > > > > The program can easily be audited, as it'll be maybe 50 lines of code... > > If the user switches VT, the keyboard needs to be unpatched. So this > approach won't fully work. However, a solution that can work is to make > the keyboard unit execute a setuid root helper to which it communicates > through a pipe. This would introduce quite some linux specific code on a lot of already complicated points to the IDE. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
> Ales wrote: > A project the size of the IDE is unauditable, given it's size. > This again is not meant to criticize the IDE - any project of the size > is unauditable. Not that it is doable for us for the IDE, but OpenBSD seems to think otherwise. But I still think not making a separation between server related and desktop security in Linux is the big problem. People that feel limited by all kinds of security features turn stuff of at random. These kinds of petty changes only increase the risk. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > The "scary" thing is the setuid root. The communication channel can be > > standard i/o and there is nothing scary about that. > > There is: a user using the keyboard unit should then distribute the > (setuid) program too, and that is not acceptable. (not for me as an FPC > developer, and most likely also not fot the user) So if you want to go > through with this, develop a separate keyboard driver for linux console > that can catch all keys. But not the standard driver. Yes, but again no difference from a wrapper that launches the program. I fully agree that it would suck to have to distribute such a wrapper or helper and that it would need to be optional. > I understand. But spawning an external setuid process and talking to that > just to get a text mode thing working in some weird cases is not one, > but two bridges too far for me... > > I mean, seriously, how many people develop on the Linux console ? > You can't even open a browser then ! I expect most people do > their work in an X-Term if they use the fp ide... Many people indeed use X. But on the Linux console, thanks to fbdev, you can get a really comfortable text mode (i.e. 1024x768 with a high res 8x16 font is still a 128x48 text mode). This makes make you can see large amounts of source at the same time, combined with a speed and responsiveness of a text mode UI. Compared to xterm, you get the VGA character set instead of the limited VT100 character set and the keyboard works better (for example shift+tab is impossible in xterm). Therefore, console is popular as well. > > By the way, I have started to talk to Andrew Morton and his reply was > > constructive. Perhaps a proper solution is possible after all. > > Great, that is the way to go !! > > Please, keep us updated on any progress you make on this :-) Sure! Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Signal handlers
On 18 Jul 2007, at 22:17, Micha Nelissen wrote: Jonas Maebe wrote: Since there are only 3 parameters, it should be possible to do this even on i386. Implemented and committed; but thinking about it, does it really matter ? It's still being executed more or less asynchronous to the application: it could be in the middle of heap manager operation or throwing exception etc... which exactly was the problem with the signal handler, and isn't really solved. It indeed only solves the problem that many functions (including some syscalls, or does this only apply to libc?) cannot be called safely during the execution of a signal handler. Crashes due to errors in the run time system itself (or corruption of the rtl structures by external code) can probably never be handled properly using exceptions, since exceptions are also part of this same run time system. Even if you use dwarf exception frame info, you may still need some RTL support during exception handling. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On Wed, 18 Jul 2007, Daniël Mantione wrote: > > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > > > > > On Wed, 18 Jul 2007, Daniël Mantione wrote: > > > > > > > > > > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > > > > > > > well then that's it... If you want to use these keys, you'll have > > > > > > to run your > > > > > > programs as root... > > > > > > > > > > > > Or use a GUI IDE like Lazarus... > > > > > > > > > > You just proposed this yourself, but before executing the IDE? > > > > > > > > ? I proposed to use a small wrapper program, which does an Exec() after > > > > setting > > > > the proper TTY properties. Not set up a communication channel with a > > > > setuid root > > > > program. The solution is worse than the problem then... > > > > > > What is bad about such a solution? > > > > It's not KIS. If you can't have certain keys without being root, well then > > you'll have to learn to live with it. This is no longer the MS-DOS age when > > everything was possible. It's a shortcoming of the platform, and for me > > this is the end of the story. The keyboard unit should in no way set up > > such a communication channel; if you absolutely want that, you can set > > it up for the IDE (I don't use it anyway), but not for the standard > > keyboard > > driver unit. Develop a driver that handles this, and use that in the IDE. > > The "scary" thing is the setuid root. The communication channel can be > standard i/o and there is nothing scary about that. There is: a user using the keyboard unit should then distribute the (setuid) program too, and that is not acceptable. (not for me as an FPC developer, and most likely also not fot the user) So if you want to go through with this, develop a separate keyboard driver for linux console that can catch all keys. But not the standard driver. > > > I can agree that some of the Linux kernel developers are braindead - seeing > > what they have done - but I don't think we should go out of our way to fix > > that. Rather, we should request that they implement a decent keyboard > > interface which allows you to detect properly the state of all keys on > > the terminal which you are currently using. > > Yes, I agree all kinds of hacks suck. However, the situation with Unix > keyboard is not "if" there should be hacks, but to what extend you go. > I.e. you can enable xterm "meta sends escape" with an escape sequence to > allow detecting alt-key combinations. However some xterms already do this > by default and start sending double escapes. We detect this with an ugly > hack. > > Some people go much further I.e. you can bypass xterm limitations by > opening a stealth connection to the X server and many people are doing it. > However, this went too far for me for now. > > Unfortunately Unix and keyboards is one hell, like it or not. There is no > proper "API" and you have to work around things to get work done. I understand. But spawning an external setuid process and talking to that just to get a text mode thing working in some weird cases is not one, but two bridges too far for me... I mean, seriously, how many people develop on the Linux console ? You can't even open a browser then ! I expect most people do their work in an X-Term if they use the fp ide... > > By the way, I have started to talk to Andrew Morton and his reply was > constructive. Perhaps a proper solution is possible after all. Great, that is the way to go !! Please, keep us updated on any progress you make on this :-) Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Signal handlers
Jonas Maebe wrote: > Since there are only 3 parameters, it should be possible to do this even > on i386. Implemented and committed; but thinking about it, does it really matter ? It's still being executed more or less asynchronous to the application: it could be in the middle of heap manager operation or throwing exception etc... which exactly was the problem with the signal handler, and isn't really solved. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > On Wed, 18 Jul 2007, Daniël Mantione wrote: > > > > > > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > > > > > well then that's it... If you want to use these keys, you'll have to > > > > > run your > > > > > programs as root... > > > > > > > > > > Or use a GUI IDE like Lazarus... > > > > > > > > You just proposed this yourself, but before executing the IDE? > > > > > > ? I proposed to use a small wrapper program, which does an Exec() after > > > setting > > > the proper TTY properties. Not set up a communication channel with a > > > setuid root > > > program. The solution is worse than the problem then... > > > > What is bad about such a solution? > > It's not KIS. If you can't have certain keys without being root, well then > you'll have to learn to live with it. This is no longer the MS-DOS age when > everything was possible. It's a shortcoming of the platform, and for me > this is the end of the story. The keyboard unit should in no way set up > such a communication channel; if you absolutely want that, you can set > it up for the IDE (I don't use it anyway), but not for the standard keyboard > driver unit. Develop a driver that handles this, and use that in the IDE. The "scary" thing is the setuid root. The communication channel can be standard i/o and there is nothing scary about that. > I can agree that some of the Linux kernel developers are braindead - seeing > what they have done - but I don't think we should go out of our way to fix > that. Rather, we should request that they implement a decent keyboard > interface which allows you to detect properly the state of all keys on > the terminal which you are currently using. Yes, I agree all kinds of hacks suck. However, the situation with Unix keyboard is not "if" there should be hacks, but to what extend you go. I.e. you can enable xterm "meta sends escape" with an escape sequence to allow detecting alt-key combinations. However some xterms already do this by default and start sending double escapes. We detect this with an ugly hack. Some people go much further I.e. you can bypass xterm limitations by opening a stealth connection to the X server and many people are doing it. However, this went too far for me for now. Unfortunately Unix and keyboards is one hell, like it or not. There is no proper "API" and you have to work around things to get work done. By the way, I have started to talk to Andrew Morton and his reply was constructive. Perhaps a proper solution is possible after all. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On Wed, 18 Jul 2007, Daniël Mantione wrote: > > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > > > well then that's it... If you want to use these keys, you'll have to > > > > run your > > > > programs as root... > > > > > > > > Or use a GUI IDE like Lazarus... > > > > > > You just proposed this yourself, but before executing the IDE? > > > > ? I proposed to use a small wrapper program, which does an Exec() after > > setting > > the proper TTY properties. Not set up a communication channel with a setuid > > root > > program. The solution is worse than the problem then... > > What is bad about such a solution? It's not KIS. If you can't have certain keys without being root, well then you'll have to learn to live with it. This is no longer the MS-DOS age when everything was possible. It's a shortcoming of the platform, and for me this is the end of the story. The keyboard unit should in no way set up such a communication channel; if you absolutely want that, you can set it up for the IDE (I don't use it anyway), but not for the standard keyboard driver unit. Develop a driver that handles this, and use that in the IDE. I can agree that some of the Linux kernel developers are braindead - seeing what they have done - but I don't think we should go out of our way to fix that. Rather, we should request that they implement a decent keyboard interface which allows you to detect properly the state of all keys on the terminal which you are currently using. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > well then that's it... If you want to use these keys, you'll have to run > > > your > > > programs as root... > > > > > > Or use a GUI IDE like Lazarus... > > > > You just proposed this yourself, but before executing the IDE? > > ? I proposed to use a small wrapper program, which does an Exec() after > setting > the proper TTY properties. Not set up a communication channel with a setuid > root > program. The solution is worse than the problem then... What is bad about such a solution? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On Wed, 18 Jul 2007, Daniël Mantione wrote: > > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > > > > > On Wed, 18 Jul 2007, Daniël Mantione wrote: > > > > > > > > > > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > > > > > On Wed, 18 Jul 2007, Ales( Katona wrote: > > > > > > > > > Why? You have your good ol' PING doing it. I agree tho that if a > > > > > wrapper > > > > > can do it for us it's safest. Or if the ide can do it on start, and > > > > > always setuid(userid) itself right after setting the proper things. I > > > > > don't see a problem with ANY program being setuid if it has a proper > > > > > reason, and is audited for it. > > > > > > > > > > But as I sayed a wrapper, of if there's a non-setuid way then of > > > > > course > > > > > that should be used. > > > > > > > > Under the assumption a setuid root program is the only possible option: > > > > > > > > The safest - and in my opinion only correct - way is to write a small > > > > setuid > > > > root program which sets the proper TTY stuff, and then executes the IDE > > > > as > > > > the normal user. > > > > > > > > The program can easily be audited, as it'll be maybe 50 lines of code... > > > > > > If the user switches VT, the keyboard needs to be unpatched. So this > > > approach won't fully work. However, a solution that can work is to make > > > the keyboard unit execute a setuid root helper to which it communicates > > > through a pipe. > > > > I object to this; The keyboard unit should not be able to do this in the > > first place. It's supposed to be read-only. If the linux kernel does not > > allow you any more to trap some weird key combinations unless you are root, > > well then that's it... If you want to use these keys, you'll have to run > > your > > programs as root... > > > > Or use a GUI IDE like Lazarus... > > You just proposed this yourself, but before executing the IDE? ? I proposed to use a small wrapper program, which does an Exec() after setting the proper TTY properties. Not set up a communication channel with a setuid root program. The solution is worse than the problem then... Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > On Wed, 18 Jul 2007, Daniël Mantione wrote: > > > > > > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > > > On Wed, 18 Jul 2007, Ales( Katona wrote: > > > > > > > Why? You have your good ol' PING doing it. I agree tho that if a wrapper > > > > can do it for us it's safest. Or if the ide can do it on start, and > > > > always setuid(userid) itself right after setting the proper things. I > > > > don't see a problem with ANY program being setuid if it has a proper > > > > reason, and is audited for it. > > > > > > > > But as I sayed a wrapper, of if there's a non-setuid way then of course > > > > that should be used. > > > > > > Under the assumption a setuid root program is the only possible option: > > > > > > The safest - and in my opinion only correct - way is to write a small > > > setuid > > > root program which sets the proper TTY stuff, and then executes the IDE > > > as > > > the normal user. > > > > > > The program can easily be audited, as it'll be maybe 50 lines of code... > > > > If the user switches VT, the keyboard needs to be unpatched. So this > > approach won't fully work. However, a solution that can work is to make > > the keyboard unit execute a setuid root helper to which it communicates > > through a pipe. > > I object to this; The keyboard unit should not be able to do this in the > first place. It's supposed to be read-only. If the linux kernel does not > allow you any more to trap some weird key combinations unless you are root, > well then that's it... If you want to use these keys, you'll have to run your > programs as root... > > Or use a GUI IDE like Lazarus... You just proposed this yourself, but before executing the IDE? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On Wed, 18 Jul 2007, Daniël Mantione wrote: > > > Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > On Wed, 18 Jul 2007, Ales( Katona wrote: > > > > > Why? You have your good ol' PING doing it. I agree tho that if a wrapper > > > can do it for us it's safest. Or if the ide can do it on start, and > > > always setuid(userid) itself right after setting the proper things. I > > > don't see a problem with ANY program being setuid if it has a proper > > > reason, and is audited for it. > > > > > > But as I sayed a wrapper, of if there's a non-setuid way then of course > > > that should be used. > > > > Under the assumption a setuid root program is the only possible option: > > > > The safest - and in my opinion only correct - way is to write a small > > setuid > > root program which sets the proper TTY stuff, and then executes the IDE as > > the normal user. > > > > The program can easily be audited, as it'll be maybe 50 lines of code... > > If the user switches VT, the keyboard needs to be unpatched. So this > approach won't fully work. However, a solution that can work is to make > the keyboard unit execute a setuid root helper to which it communicates > through a pipe. I object to this; The keyboard unit should not be able to do this in the first place. It's supposed to be read-only. If the linux kernel does not allow you any more to trap some weird key combinations unless you are root, well then that's it... If you want to use these keys, you'll have to run your programs as root... Or use a GUI IDE like Lazarus... Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > On Wed, 18 Jul 2007, Ales( Katona wrote: > > > Why? You have your good ol' PING doing it. I agree tho that if a wrapper > > can do it for us it's safest. Or if the ide can do it on start, and > > always setuid(userid) itself right after setting the proper things. I > > don't see a problem with ANY program being setuid if it has a proper > > reason, and is audited for it. > > > > But as I sayed a wrapper, of if there's a non-setuid way then of course > > that should be used. > > Under the assumption a setuid root program is the only possible option: > > The safest - and in my opinion only correct - way is to write a small setuid > root program which sets the proper TTY stuff, and then executes the IDE as > the normal user. > > The program can easily be audited, as it'll be maybe 50 lines of code... If the user switches VT, the keyboard needs to be unpatched. So this approach won't fully work. However, a solution that can work is to make the keyboard unit execute a setuid root helper to which it communicates through a pipe. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Op Wed, 18 Jul 2007, schreef Jonas Maebe: > > On 17 Jul 2007, at 23:20, Marco van de Voort wrote: > > > > The result is that the keyboard unit is no longer able to catch keys > > > like > > > escape, shift+tab alt+F1..F12 etc. on the Linux console. This affects > > > the > > > Free Pascal IDE and any other program using the keyboard unit. > > > > Install the IDE setuid. > > That would be an extremely bad idea with the current stability record of the > IDE. A possible way out is to install the IDE setuid root, then drop all capabilities except the right one and change uid. It is not a good solution, because then every program using the keyboard would need such a trick and I'm sure one of your users will code a security hole sooner or later this way. However, for the IDE itself, it could be effective. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On Wed, 18 Jul 2007, Ales( Katona wrote: > Why? You have your good ol' PING doing it. I agree tho that if a wrapper > can do it for us it's safest. Or if the ide can do it on start, and > always setuid(userid) itself right after setting the proper things. I > don't see a problem with ANY program being setuid if it has a proper > reason, and is audited for it. > > But as I sayed a wrapper, of if there's a non-setuid way then of course > that should be used. Under the assumption a setuid root program is the only possible option: The safest - and in my opinion only correct - way is to write a small setuid root program which sets the proper TTY stuff, and then executes the IDE as the normal user. The program can easily be audited, as it'll be maybe 50 lines of code... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Op Wed, 18 Jul 2007, schreef Sergei Gorelkin: > Jonas Maebe wrote: > > > > On 18 Jul 2007, at 14:08, Jonas Maebe wrote: > > > > > > Install the IDE setuid. > > > > > > That would be an extremely bad idea with the current stability record > > > of the IDE. > > > > Not to mention that it allows you to open and overwrite any arbitrary > > file. > > > > Looking at that kernel patch, I see that it requires not uid=0, but rather > certain caller's capability present. > I don't have deep knowledge of the subject, but 'capability' sounds like > 'privilege' (in Windows terms) for me. If it is so, then probably there is a > way to solve the problem by assigning the required capability to IDE user(s) > or process. Yes, you need a certain capability, but in practise this means you must be root. This is because: * You can only drop a capability, not get a capability as a process. * Root has all capabilities, users don't have any capabilities. However, there is the SETPCAP capability, where a process can set the capabilities of another process. So, a setuid helper program cuild assign the needed capability if certain conditions are met. Unfortunately due to a security hole SETPCAP has been revoked from even root. Without kernel modification this possible solution is unfortunately sabotaged. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Op Wed, 18 Jul 2007, schreef Michael Van Canneyt: > > > On Wed, 18 Jul 2007, Marco van de Voort wrote: > > > > On 18 Jul 2007, at 14:08, Jonas Maebe wrote: > > > > > > >> Install the IDE setuid. > > > > > > > > That would be an extremely bad idea with the current stability > > > > record of the IDE. > > > > > > Not to mention that it allows you to open and overwrite any arbitrary > > > file. > > > > Yes. Just like we all have for decades. And no, it is not ideal, but > > apparantly that is what the kernel devels want as the only way to access the > > full terminal capability. > > You cannot distribute a tool which creates a security hole as large as from > here till Tokio. That would not look good the day it is discovered, and > arguments like "the kernel forcing us to do so" will not help us then. > > It just means you'll have less functionality. > How does midnight commander solve it? As far as I know, it also > has strange keyboard combinations ? Probably Midnight Commander doesn't solve it. Ctrl+arrows works in mc, but I expect them to use the TIOCLINUX, subfunction 6, to get the shift states. The keyboard unit makes use of this ioctl too, but it ain't enough to catch combinations like alt+fx, escape without delay, and being able to tell the difference between F11 and shift+F1. I believe mc doesn't do this. Still, there is the semiraw mode, which is another way to catch keys, but the semi raw mode has the disadvantage that it is keymap ignorant. You need your own keymaps like XFree86 (XFree86 probably uses semi-raw, or full raw mode). Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Ales wrote: Strawman yes, but if we setuid to userid right after setting the console stuff, there's nothing left to audit. We're not malicious software makers so there's no chance anything else could happen? Or am I missing something here? eg: fp starts fp sets itself to uid 0 fp sets the required things as root fp sets itself to original userid fp finishes init I don't see a problem with that. It's not nice to have a suid binary requirement, but if there's no other way? If there's no other way, it would still be nicer to have the suid code in an entirely seperate executable. Running any complex program as suid always makes me nerveous - and yes, I very much would have second thoughts about even running the IDE at all. Apart from that, your plan could work. I just really, really hope we find some other way. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Strawman yes, but if we setuid to userid right after setting the console stuff, there's nothing left to audit. We're not malicious software makers so there's no chance anything else could happen? Or am I missing something here? eg: fp starts fp sets itself to uid 0 fp sets the required things as root fp sets itself to original userid fp finishes init I don't see a problem with that. It's not nice to have a suid binary requirement, but if there's no other way? Christian Iversen wrote / napísal(a): > Ales wrote: >> Why? You have your good ol' PING doing it. > > Unbelievable strawman argument there. > > This is not at all a critique of the IDE, but please don't compare the > complexity of "ping" and "fpide"(!) > >> I agree tho that if a wrapper can do it for us it's safest. Or if the >> ide can do it on start, and always setuid(userid) itself right after >> setting the proper things. I don't see a problem with ANY program >> being setuid if it has a proper reason, and is audited for it. > > There is a very serious limit as to how many lines of code one can > audit. A project the size of the IDE is unauditable, given it's size. > This again is not meant to criticize the IDE - any project of the size > is unauditable. > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Ales wrote: Why? You have your good ol' PING doing it. Unbelievable strawman argument there. This is not at all a critique of the IDE, but please don't compare the complexity of "ping" and "fpide"(!) I agree tho that if a wrapper can do it for us it's safest. Or if the ide can do it on start, and always setuid(userid) itself right after setting the proper things. I don't see a problem with ANY program being setuid if it has a proper reason, and is audited for it. There is a very serious limit as to how many lines of code one can audit. A project the size of the IDE is unauditable, given it's size. This again is not meant to criticize the IDE - any project of the size is unauditable. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Why? You have your good ol' PING doing it. I agree tho that if a wrapper can do it for us it's safest. Or if the ide can do it on start, and always setuid(userid) itself right after setting the proper things. I don't see a problem with ANY program being setuid if it has a proper reason, and is audited for it. But as I sayed a wrapper, of if there's a non-setuid way then of course that should be used. > > You cannot seriously mean that. I agree 100% with Jonas here. PLEASE > rethink your position Ales :-) > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Ales wrote: And to add to my last setuid stuff.. I think that if we properly audit the IDE code so that: a) fpc is called in the uid of the original ide starter b) the "console" is run in the uid of the original ide starter c) compiler programs are called in the uid of the original IDE starter I think it's ok to use setuid after these. Ofcourse, depending on how the IDE executes all the externals, it might be a trouble. But if we do some typical fork, it shouldn't be so difficult (I'm willing to do this should we decide to go this route). There is absolutely no clean way to use setuid in a program the size of the IDE. Trust me. It is vaguely possible that a very small (think "less than 100 LOC") wrapper could be generated, which will simply set certain configuration parameters of the PTY that the IDE is attached to. I imagine that this would work. This could be distributed, and called from the IDE after startup. The entire IDE would then be run completely as normal, by the user. Even with such a small wrapper, one would have to put a big fat warning in the README file and similar places. In the Debian package, debconf should ask the user if s/he is ok with installing a suid program. If this is not feasible, then the IDE will have to be redistributed with reduced functionality. You just cannot compromise when it comes to security matters. Ever. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Ales wrote: While I agree that it could cause some PR trouble, I don't see how this is our problem. It's not like anyone blames the software makers for windows security issues... You cannot seriously mean that. I agree 100% with Jonas here. PLEASE rethink your position Ales :-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Michael Van Canneyt wrote: On Wed, 18 Jul 2007, Marco van de Voort wrote: On 18 Jul 2007, at 14:08, Jonas Maebe wrote: Install the IDE setuid. That would be an extremely bad idea with the current stability record of the IDE. Not to mention that it allows you to open and overwrite any arbitrary file. Yes. Just like we all have for decades. And no, it is not ideal, but apparantly that is what the kernel devels want as the only way to access the full terminal capability. You cannot distribute a tool which creates a security hole as large as from here till Tokio. That would not look good the day it is discovered, and arguments like "the kernel forcing us to do so" will not help us then. It just means you'll have less functionality. How does midnight commander solve it? As far as I know, it also has strange keyboard combinations ? Sorry for joining the discussion so late, but what special key combos are we talking about? And what changed in the kernel? I agree that it does sound absurd to require root privs - and of course it goes without saying that the IDE _cannot_ under any circumstance be distributed to run as +s, it just cannnot happen, period. These privileges that we are talking about, are they transferrable between processes? In that case, we could write a small setuid wrapper to setup the terminal, then exec the IDE without privs. Under any circumstance, if there really isn't any New And Improved way to do this sans root, we should bring it up on the kernel mailing list. I can do that, if need be - I'm always quite interested in security matters. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
And to add to my last setuid stuff.. I think that if we properly audit the IDE code so that: a) fpc is called in the uid of the original ide starter b) the "console" is run in the uid of the original ide starter c) compiler programs are called in the uid of the original IDE starter I think it's ok to use setuid after these. Ofcourse, depending on how the IDE executes all the externals, it might be a trouble. But if we do some typical fork, it shouldn't be so difficult (I'm willing to do this should we decide to go this route). Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL WIN64: Entry point not found
O/H Vincent Snijders έγραψε: Mark - WBIsoft.COM schreef: I think the calling convention be STDCALL ? IIRC, that is the same on win64. Are you sure about this ? AFAIK, they have opposite order of arguments in stack. In cdecl caller will clean up stack after the call (raise ESP) while in stdcall this is job of called function. I see no reason to change this because of 32\64\128 bit architecture of CPU. Anyway, the calling convention for a Firebird UDF is still cdecl either for x86_64 or x86_32. PS: Don't forget to use ib_util_malloc() from ib_util.dll to allocate memory for the UDF result string declared as FREE_IT. regards, -- Dimitrios Chr. Ioannidis Firebird Project http://www.firebirdsql.org ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Jonas Maebe wrote / napísal(a): Oh and btw, setuid is generaly used afaik. It's a normal thing to allow temporary root access on normal programs in linux. Ofcourse doing it on something like fpIDE is somewhat questionable (heh the possibilities :D), but I don't see it as such a great risk. The more I think about it it's pretty valid for desktop users, altough they should be asked about it I guess. Ofcourse if there IS a better way... >> While I agree that it could cause some PR trouble, I don't see how this >> is our problem. It's not like anyone blames the software makers for >> windows security issues... > > This has nothing at all to do with "pr trouble", but with not > installing a local rootkit with every FPC install. > > I'm just speechless, I really can't believe what I'm reading here... > > > Jonas > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Why? If they allow it it's their problem. If there's no sane way to do something and we do it this way it's their problem that it's allowed... I just don't see as how this whole thing is "our" problem. I guess we could ask on install, "do you want a rootkit or no shortcuts?"... > > This has nothing at all to do with "pr trouble", but with not > installing a local rootkit with every FPC install. > > I'm just speechless, I really can't believe what I'm reading here... > > > Jonas > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL WIN64: Entry point not found
Luc Vigato, Sita Software schreef: Here an little test DLL (SitaUdfLib.pas). It also don't work with firebird 2.1 64bit version. How can I test this, without installing firebird? Do you have another host application? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
> On 18 Jul 2007, at 17:42, Marco van de Voort wrote: > > >> arguments like "the kernel forcing us to do so" will not help us > >> then. > > > > What is the security hole exactly? > > If you install the IDE as setuid root, then every user starting the > IDE will run the IDE as if he were root. That means he can open and > modify every single file on the system. And overwrite any binary with > an own written program by just configuring the proper exe output > directory in the IDE. > > And by using the shell functionality of the IDE, he can also open a > root shell if that's more comfortable for him than using the IDE itself. That might indeed be slightly too much. OTOH it would make an important point :-) Seriously, in how many distro's is this "feature" active? Can it be turned off? Can we assume that desktop distro's as ubuntu aren't going to do this? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On 18 Jul 2007, at 18:01, Ales( Katona <[EMAIL PROTECTED]> wrote: While I agree that it could cause some PR trouble, I don't see how this is our problem. It's not like anyone blames the software makers for windows security issues... This has nothing at all to do with "pr trouble", but with not installing a local rootkit with every FPC install. I'm just speechless, I really can't believe what I'm reading here... Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Michael Van Canneyt wrote: > On Wed, 18 Jul 2007, Marco van de Voort wrote: >> > On 18 Jul 2007, at 14:08, Jonas Maebe wrote: >> > >> > >> Install the IDE setuid. >> > > >> > > That would be an extremely bad idea with the current stability >> > > record of the IDE. >> > >> > Not to mention that it allows you to open and overwrite any arbitrary >> > file. >> >> Yes. Just like we all have for decades. And no, it is not ideal, but >> apparantly that is what the kernel devels want as the only way to access >> the >> full terminal capability. > > You cannot distribute a tool which creates a security hole as large as > from > here till Tokio. That would not look good the day it is discovered, and > arguments like "the kernel forcing us to do so" will not help us then. > > It just means you'll have less functionality. > How does midnight commander solve it? As far as I know, it also > has strange keyboard combinations ? Yes, exactly. And as far as I know, this is one of the most common complaints from people used to other NC-like managers running on other systems (compare this to users used to TP/BP IDE). That's actually a very good example. ;-) Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
While I agree that it could cause some PR trouble, I don't see how this is our problem. It's not like anyone blames the software makers for windows security issues... > > If you install the IDE as setuid root, then every user starting the > IDE will run the IDE as if he were root. That means he can open and > modify every single file on the system. And overwrite any binary with > an own written program by just configuring the proper exe output > directory in the IDE. > > And by using the shell functionality of the IDE, he can also open a > root shell if that's more comfortable for him than using the IDE itself. > > > Jonas > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On 18 Jul 2007, at 17:42, Marco van de Voort wrote: On Wed, 18 Jul 2007, Marco van de Voort wrote: On 18 Jul 2007, at 14:08, Jonas Maebe wrote: Install the IDE setuid. That would be an extremely bad idea with the current stability record of the IDE. Not to mention that it allows you to open and overwrite any arbitrary file. Yes. Just like we all have for decades. No, we haven't. And no, it is not ideal, but apparantly that is what the kernel devels want as the only way to access the full terminal capability. You cannot distribute a tool which creates a security hole as large as from here till Tokio. That would not look good the day it is discovered, and arguments like "the kernel forcing us to do so" will not help us then. What is the security hole exactly? If you install the IDE as setuid root, then every user starting the IDE will run the IDE as if he were root. That means he can open and modify every single file on the system. And overwrite any binary with an own written program by just configuring the proper exe output directory in the IDE. And by using the shell functionality of the IDE, he can also open a root shell if that's more comfortable for him than using the IDE itself. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
> On Wed, 18 Jul 2007, Marco van de Voort wrote: > > > > On 18 Jul 2007, at 14:08, Jonas Maebe wrote: > > > > > > >> Install the IDE setuid. > > > > > > > > That would be an extremely bad idea with the current stability > > > > record of the IDE. > > > > > > Not to mention that it allows you to open and overwrite any arbitrary > > > file. > > > > Yes. Just like we all have for decades. And no, it is not ideal, but > > apparantly that is what the kernel devels want as the only way to access the > > full terminal capability. > > You cannot distribute a tool which creates a security hole as large as from > here till Tokio. That would not look good the day it is discovered, and > arguments like "the kernel forcing us to do so" will not help us then. What is the security hole exactly? Or does Linux allow any user to change kbd, even if he is not on the console? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
> On Tuesday 17 July 2007 11:20:54 pm Marco van de Voort wrote: > > > Apparently someone suddenly got a good idea that you need to be root to > > > reprogram the keyboard, and got a patch merged into the Linux kernel: > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit > > >diff;h=0b360adbdb54d5b98b78d57ba0916bc4b8871968 > > > > > minor breakage is mentioned, you should have tried an mm kernel > and complained :-) Like everything these woolheads think of, it is very nice for trained admins, and people used to read kernel lists, how-to's (and spend overly amounts of time on it). However the problem is that this kind of paranoia (since I assume currently it is only allowed for people using a valid tty handle) creates enormous deployment problems. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] DLL WIN64: Entry point not found
Here an little test DLL (SitaUdfLib.pas). It also don't work with firebird 2.1 64bit version. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Felipe Monteiro de Carvalho Sent: mercredi 18 juillet 2007 16:48 To: FPC developers' list Subject: Re: [fpc-devel] DLL WIN64: Entry point not found On 7/18/07, Luc Vigato, Sita Software <[EMAIL PROTECTED]> wrote: > The export table seems to be OK, but from where comes the error "Entry point > not found"? I don't have any idea. I'm open for all suggestions. Try to reproduce with a small DLL (the smaller the better). And then post the source code here. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel begin 666 SitaUdfLib.pas M;&EB2!3:71A561F3&EB.PT*>R1M;V1E(&]B:F9P8WU[)[EMAIL PROTECTED] M"F9U;F-T:6]N(%5$1E]3:6UP;&4H
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On Tuesday 17 July 2007 11:20:54 pm Marco van de Voort wrote: > > Apparently someone suddenly got a good idea that you need to be root to > > reprogram the keyboard, and got a patch merged into the Linux kernel: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit > >diff;h=0b360adbdb54d5b98b78d57ba0916bc4b8871968 > > minor breakage is mentioned, you should have tried an mm kernel and complained :-) http://www.ussg.iu.edu/hypermail/linux/kernel/0510.2/0483.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On Wed, 18 Jul 2007, Marco van de Voort wrote: > > On 18 Jul 2007, at 14:08, Jonas Maebe wrote: > > > > >> Install the IDE setuid. > > > > > > That would be an extremely bad idea with the current stability > > > record of the IDE. > > > > Not to mention that it allows you to open and overwrite any arbitrary > > file. > > Yes. Just like we all have for decades. And no, it is not ideal, but > apparantly that is what the kernel devels want as the only way to access the > full terminal capability. You cannot distribute a tool which creates a security hole as large as from here till Tokio. That would not look good the day it is discovered, and arguments like "the kernel forcing us to do so" will not help us then. It just means you'll have less functionality. How does midnight commander solve it? As far as I know, it also has strange keyboard combinations ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL WIN64: Entry point not found
On 7/18/07, Luc Vigato, Sita Software <[EMAIL PROTECTED]> wrote: The export table seems to be OK, but from where comes the error "Entry point not found"? I don't have any idea. I'm open for all suggestions. Try to reproduce with a small DLL (the smaller the better). And then post the source code here. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] DLL WIN64: Entry point not found
The export table seems to be OK, but from where comes the error "Entry point not found"? I don't have any idea. I'm open for all suggestions. Result of MiTeC EXE explorer. Dump of file \\pc-luc\DeRaoul\SitaUdfLib.dll Created by EXE Explorer 1.0.0.0 - Copyright C 2006 Michal Mutl DOS HEADER Magic number: 0x5A4D Bytes on last page of file: 0x0090 Pages in file: 0x0003 Relocations: 0x Size of header in paragraphs: 0x0004 Minimum extra paragraphs needed: 0x Maximum extra paragraphs needed: 0x Initial (relative) SS value: 0x Initial SP value: 0x00B8 Checksum: 0x Initial IP value: 0x Initial (relative) CS value: 0x File address of relocation table: 0x0040 Overlay number: 0x Reserved[0]: 0x Reserved[1]: 0x Reserved[2]: 0x Reserved[3]: 0x OEM identifier: 0x OEM information: 0x Reserved[0]: 0x Reserved[1]: 0x Reserved[2]: 0x Reserved[3]: 0x Reserved[4]: 0x Reserved[5]: 0x Reserved[6]: 0x Reserved[7]: 0x Reserved[8]: 0x Reserved[9]: 0x File address of new exe header: 0x0080 FILE HEADER Signature: 0x4550 (Portable Executable) Machine: 64-bit AMD Number of sections:5 Timestamp: 1/1/1970 Pointer to symbol table: 0x000E9D40 Number of symbols: 11975 Size of optional header: 240 Characteristics: 0x220F OPTIONAL HEADER Magic: 0x020B (PE32+ (64bit)) Linker version:2.15 Size of code: 635888 Size of initialized data: 312064 Size of uninitialized: 11184 Address of entry point:0x00021160 Base of code: 0x1000 Image base:0x1000 Section alignment: 4096 File alignment:512 Operating system version: 4.0 Image version: 1.0 Subsystem version: 4.0 Win32 version value: 0 Size of image: 983040 B Size of headers: 1024 Checksum: 0 Subsystem: Console DLL characteristics: 0x Size of stack reserve: 262144 Size of stack commit: 4096 Size of heap reserve: 1048576 Size of heap commit: 4096 Loader flags: 0x Number of RVA: 16 CHECKSUMS CRC32: B095FA5E MD4: CD59C3109BE02443514A9280F081430D MD5: 0897202B5DE9BD803E6B3A1AB98659B3 SHA1: 1E1C9EFB3F9399EF63F5029516C2D601A6C58126 SECTIONS .text Virtual address: 0x1000 Virtual size:635888 Raw data offset: 0x0400 Raw data size: 635888 Characteristics: 0x60500020 Relocations: 0 Line numbers:0 .data Virtual address: 0x0009D000 Virtual size:312064 Raw data offset: 0x0009B800 Raw data size: 312064 Characteristics: 0xC0500040 Relocations: 0 Line numbers:0 .bss Virtual address: 0x000EA000 Virtual size:11184 Raw data offset: 0x Raw data size: 0 Characteristics: 0xC0500080 Relocations: 0 Line numbers:0 .idata Virtual address: 0x000ED000 Virtual size:6240 Raw data offset: 0x000E7C00 Raw data size: 6240 Characteristics: 0xC0400040 Relocations: 0 Line numbers:0 .edata Virtual address: 0x000EF000 Virtual size:1856 Raw data offset: 0x000E9600 Raw data size: 1856 Characteristics: 0x40400040 Relocations: 0 Line numbers:0 DIRECTORIES Exports Section: .edata RVA: 0x000EF000 Size: 1856 Imports Section: .idata RVA: 0x000ED000 Size: 6240 EXPORTS AddMonth Ordinal: 0x0001 Address: 0x0002A850 AddYear Ordinal: 0x0002 Address: 0x0002A710 Age Ordinal: 0x0003 Address: 0x0002A5D0 AgeDebutAnnee Ordinal: 0x0004 Address: 0x0002AA10 AgeFinAnnee Ordinal: 0x0005 Address: 0x0002A9D0 Annee Ordinal: 0x0006 Address: 0x0002A990 BlobContainsString Ordinal: 0x0007 Address: 0x00024A10 BlobContainsStringBefore Ordinal: 0x0008 Address: 0x00027E80 BlobMaxSegmentLength Ordinal: 0x0009 Address: 0x00027B00 BlobSegmentCount Ordinal: 0x000A Address: 0x00025EE0 BlobSize Ordinal: 0x000B Address: 0x00033E40 Chiffre Ordinal: 0x000C Address: 0x00033BE0 CodeSemaine Ordinal: 0x000D Address: 0x00033460 ConversionChiffreLettre Ordinal: 0x000E Address: 0x00032C50 CopyDebut Ordinal: 0x000F Address: 0x0003
Re: [fpc-devel] DLL WIN64: Entry point not found
Ok, try the MiTeC EXE explorer from http://www.mitec.cz I use it for my 64bit windows dll's ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
> On 18 Jul 2007, at 14:08, Jonas Maebe wrote: > > >> Install the IDE setuid. > > > > That would be an extremely bad idea with the current stability > > record of the IDE. > > Not to mention that it allows you to open and overwrite any arbitrary > file. Yes. Just like we all have for decades. And no, it is not ideal, but apparantly that is what the kernel devels want as the only way to access the full terminal capability. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] tlibrary3 test
What is the purpose of the tlibrary3 test: http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/tests/test/tlibrary3.pp?view=markup It does not compile on win64, because there is no unit initc, because there is not cygwin.dll for win64. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Jonas Maebe wrote: On 18 Jul 2007, at 14:08, Jonas Maebe wrote: Install the IDE setuid. That would be an extremely bad idea with the current stability record of the IDE. Not to mention that it allows you to open and overwrite any arbitrary file. Looking at that kernel patch, I see that it requires not uid=0, but rather certain caller's capability present. I don't have deep knowledge of the subject, but 'capability' sounds like 'privilege' (in Windows terms) for me. If it is so, then probably there is a way to solve the problem by assigning the required capability to IDE user(s) or process. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Running test suite for 2.1.4 on linux/sparc
Mark Morgan Lloyd wrote: Ah- the kernel buffer is full of "Kernel unaligned access" messages. What I can't say is whether this is the result of testing or because of something that was being done on this machine a few minutes ago, however this is suspiciously similar to the fault I was getting in Lazarus. I'll leave the system in its current state if I can in case there's anything worth checking. Any hints appreciated :-) I'm really not experienced with gdb etc., a logic analyser is far more my style. However as far as I can tell the third thread bombs immediately after creation (this is an aggregate of several sessions, so I don't guarantee the addresses): 0x0004decc in CTHREADS_CBEGINTHREAD$POINTER$LONGWORD$TTHREADFUNC$POINTER$LONGWORD$LONGINT$$LONGINT () (gdb) 0xf7d64640 in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0 .. 0xf7d486c8 in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0 (gdb) [New Thread 16386 (LWP 6259)] 0xf7d486cc in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0 (gdb) 0xf7d486d0 in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0 (gdb) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16386 (LWP 6259)] 0x9de3bfa0 in ?? () (gdb) info threads * 3 Thread 16386 (LWP 6259) 0x9de3bfa0 in ?? () 2 Thread 32769 (LWP 6258) 0xf7e903b4 in poll () from /lib/v9/libc.so.6 1 Thread 16384 (LWP 6208) 0xf7d486d0 in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0 .. 6207 pts/7S+ 0:02 gdb -d ../../../test tmt1 6208 pts/7T 0:00 /fpcbuild-2.1.4/fpcsrc/tests/output/sparc-linux/test/tmt1 6258 pts/7T 0:00 /fpcbuild-2.1.4/fpcsrc/tests/output/sparc-linux/test/tmt1 6259 pts/7T 0:00 /fpcbuild-2.1.4/fpcsrc/tests/output/sparc-linux/test/tmt1 For the moment I'm reading that as thread 1 (6208) is the original program, threads 1 and 2 (6208, 6258) are somewhere in kernel space and thread 3 (6259) has been started with dud state- pc, npc or something... not sure but I don't much like the look of the stack which appears to be at a similarly indeterminate address. I need to spend time trying to get to grips with gdb etc. :-/ -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On 18 Jul 2007, at 14:08, Jonas Maebe wrote: Install the IDE setuid. That would be an extremely bad idea with the current stability record of the IDE. Not to mention that it allows you to open and overwrite any arbitrary file. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
On 17 Jul 2007, at 23:20, Marco van de Voort wrote: The result is that the keyboard unit is no longer able to catch keys like escape, shift+tab alt+F1..F12 etc. on the Linux console. This affects the Free Pascal IDE and any other program using the keyboard unit. Install the IDE setuid. That would be an extremely bad idea with the current stability record of the IDE. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Signal handlers
On 17 Jul 2007, at 23:43, Micha Nelissen wrote: SignalToRunError is a signal handler, but it calls an ErrorProc calling many functions, like CRelocateThreadVar (for accessing the exception stack), GetMem (to allocate an exception object); are these functions guaranteed to run correctly in a signal handler ? Probably not. For darwin/ppc, I actually do it differently (for another reason, but that's not relevant here): I change the signal context to return to HandleErrorAddrFrame, putting the required parameters (runerror number, program counter/instruction pointer, stack pointer) in the parameter registers of the context. Since there are only 3 parameters, it should be possible to do this even on i386. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] DLL WIN64: Entry point not found
I have tried at the moment the DLL only with PE Explorer PE Explorer gives an error . I don't know about other dependancy checker. When you give me an other depandancy checker I try it. When loading DLL with PE Explorer 18.07.2007 13:47:09 : Open File: D:\Fichiers echange\DeRaoul\SitaUdfLib.dll 18.07.2007 13:47:10 : File size: 957760 bytes. 18.07.2007 13:47:10 : Using the Plug-in subsystem... 18.07.2007 13:47:10 : Upack Unpacker Plug-in: Executing... 18.07.2007 13:47:10 : Upack Unpacker Plug-in: The file is not Upacked. 18.07.2007 13:47:10 : Upack Unpacker Plug-in: not accomplished. 18.07.2007 13:47:10 : UPX Unpacker Plug-in: Executing... 18.07.2007 13:47:10 : UPX Unpacker Plug-in: The file is not UPXed. 18.07.2007 13:47:10 : UPX Unpacker Plug-in: not accomplished. 18.07.2007 13:47:10 : The Plug-in subsystem finished. 18.07.2007 13:47:10 : MS-DOS Header Size: 0040h 18.07.2007 13:47:10 : MS-DOS Header: OK 18.07.2007 13:47:10 : Next Header OFFSET: 0080h 18.07.2007 13:47:10 : PE Signature: OK 18.07.2007 13:47:10 : Calculating Checksum: SUCCESS (Header's Checksum: h / Real Checksum: 000F264Bh) 18.07.2007 13:47:10 : EOF Position: 000E9D40h (957760) 18.07.2007 13:47:10 : Warning! Section <.data> (1) extends beyond the raw file offset of section <.bss> (2). 18.07.2007 13:47:10 : Error! (Step: Examining Resources) 18.07.2007 13:47:10 : Errors detected! Opening file in SAFE MODE... 18.07.2007 13:47:10 : Done. PE Explorer - Dependancy scanner - Result // Generated by PE Explorer 1.99 (www.heaventools.com) // File name: D:\Fichiers echange\DeRaoul\SitaUdfLib.dll // Created : 18.07.2007 13:48 // Type : Dependencies Version Info not available. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark - WBIsoft.COM Sent: mercredi 18 juillet 2007 12:37 To: FPC developers' list Subject: Re: [fpc-devel] DLL WIN64: Entry point not found Wasn't aware CDECL on Win64 was the same as STDCALL, if so then is the export table correct - have you checked with a dependancy checker ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL WIN64: Entry point not found
Wasn't aware CDECL on Win64 was the same as STDCALL, if so then is the export table correct - have you checked with a dependancy checker ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL WIN64: Entry point not found
Mark - WBIsoft.COM schreef: I think the calling convention be STDCALL ? IIRC, that is the same on win64. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL WIN64: Entry point not found
I think the calling convention be STDCALL ? Mark - Original Message - From: "Luc Vigato, Sita Software" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 18, 2007 10:43 AM Subject: [fpc-devel] DLL WIN64: Entry point not found Hello, I have compiled a DLL under Win64. It's a UDF-library for Firbird 2.1. Under Linux 64bit all things are working, only in WIN64 not. The problem is that Firebird says that he cannot find the Entry Point of each of my functions. It's not a Firebird problem, i have made a test application who calls the function from the DLL and i have the same error "entry point not found". Calling convention is: cdecl Can someone help me please ? These is my command line to compile the library. fpc -S2 -Sh -dFREE_IT -Fu../Units SitaUdfLib.dpr Output of fpc - Free Pascal Compiler version 2.1.5 [2007/05/31] for x86_64 Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Win64 for x64 Compiling SitaUdfLib.dpr Compiling UnitFonctionUdfString.pas Linking SitaUdfLib.dll 977 lines compiled, 0.5 sec, 635888 bytes code, 312064 bytes data 1 note(s) issued ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date: 17/07/2007 18:30 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] DLL WIN64: Entry point not found
Hello, I have compiled a DLL under Win64. It's a UDF-library for Firbird 2.1. Under Linux 64bit all things are working, only in WIN64 not. The problem is that Firebird says that he cannot find the Entry Point of each of my functions. It's not a Firebird problem, i have made a test application who calls the function from the DLL and i have the same error "entry point not found". Calling convention is: cdecl Can someone help me please ? These is my command line to compile the library. fpc -S2 -Sh -dFREE_IT -Fu../Units SitaUdfLib.dpr Output of fpc - Free Pascal Compiler version 2.1.5 [2007/05/31] for x86_64 Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Win64 for x64 Compiling SitaUdfLib.dpr Compiling UnitFonctionUdfString.pas Linking SitaUdfLib.dll 977 lines compiled, 0.5 sec, 635888 bytes code, 312064 bytes data 1 note(s) issued ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graphh.inc - few questions.
Thanks, Jonas. I will deep inside it.
2007/7/16, Jonas Maebe <[EMAIL PROTECTED]>:
On 14 Jul 2007, at 16:01, Evgeniy Ivanov wrote:
> I'm doing sdlgraph - so I put my self to packages/base/graph.
graph probably has to be moved to packages/extra, so it can easily
use things like sdl and the (Mac OS X) universal interfaces.
> I can't understand the method (where are they used?) using routines in
> TModeInfo (from graphh.inc).
> In custom graph modules it's used in such way:
> mode.PutPixel:={$ifdef [EMAIL PROTECTED];
> But in windows and go32v2 there are no any routines for PutPixel from
> interface.
They don't need to be in the interface. PutPixel is a procedure
variable, and the only thing that needs to be in the interface (and
it's declared in graphh.inc, which is included in the interface of
the go32v2 and win32 unts). The procedures which are assigned to this
procvar do not have to be in the interface.
> I mean someting like
> PutPixel := @custom_PutPixel; (PutPixel :=
> @libvga_PutPixelProc; - in the unix graph.pp).
>
> So, if there are no such assignations (sorry, I don't know the
> right word)
> PutPixelDefault from graph.inc will be used...
> And it is:
> procedure PutPixelDefault(X,Y: smallint; Color: Word);
> begin
> Writeln(stderr,'Error: Not in graphics mode (use InitGraph and
> test
> GraphResult afterwards)');
> Halt(1);
> end;
>
> But windows module works...
Have a look at QueryAdapterInfo in graph.pp of go32v2. It has many
blocks like this:
InitMode(mode);
{ now add all standard VGA modes... }
mode.DriverNumber:= LowRes;
mode.HardwarePages:= 0;
mode.ModeNumber:=0;
mode.ModeName:='320 x 200 VGA';
mode.MaxColor := 256;
mode.PaletteSize := mode.MaxColor;
mode.DirectColor := FALSE;
mode.MaxX := 319;
mode.MaxY := 199;
mode.DirectPutPixel:={$ifdef [EMAIL PROTECTED];
> mode.PutPixel:={$ifdef [EMAIL PROTECTED];
mode.GetPixel:={$ifdef [EMAIL PROTECTED];
mode.SetRGBPalette := {$ifdef [EMAIL PROTECTED];
mode.GetRGBPalette := {$ifdef [EMAIL PROTECTED];
mode.SetAllPalette := {$ifdef [EMAIL PROTECTED]
SetVGARGBAllPalette;
mode.SetVisualPage := {$ifdef [EMAIL PROTECTED];
mode.SetActivePage := {$ifdef [EMAIL PROTECTED];
mode.InitMode := {$ifdef [EMAIL PROTECTED];
mode.XAspect := 1;
mode.YAspect := 1;
AddMode(mode);
When switching to a mode, initgraph will assign the putpixel field of
that mode to the global putpixel procvar.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
E.I.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
