Turbo Pascal/legacy data file issue.

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Turbo Pascal/legacy data file issue.

Lowell C. Savage
Has anyone come up with a set of routines for converting between Turbo
Pascal's 6-byte "real" format and FPC's real number format?

I am trying to use FPC to update a legacy TP 5.5 program.  I've got most of
the "major" issues solved and am now finding that I'm having trouble
reading legacy data files.  Many of these data file are "file of XXXRec"
where "XXXRec" is a rather large and complex Record containing strings,
integers, bytes, enumerated types, and reals.

My problem is that I am going to need to be able to read these existing
files (without modification) into the new version of the program.

I've been able to use the "{$PACKRECORDS 1}" and "{$PACKENUMS 1}"
directives to take care of everything else.  But now I realize that Turbo
Pascal used a 6-byte real representation while FPC uses either a 4 or 8-bit
representation.

It appears that I'm going to need to make some kind of a special type,
perhaps a packed record with a "byte", a "smallint" and a 4-byte
"longword".  Then, I read this value from the existing file and convert it
into a "real".  Then, when I want to write the file (or another file) I
convert back to this record type when I fill the record I'm going to write.

Here's a simple program to demonstrate the issue.  In Turbo Pascal 5.5
(Downloaded from http://bdn.borland.com/article/0,1410,20803,00.html) this
code generates a 12-byte file.  FPC generates a 16-byte file.  (Actually,
the preprocessor directives shown appear to have no effect on this
code--not complaining since the docs don't make it appear that it should,
just pointing it out.)

Program testrec;
{$IFDEF FPC}
{$MODE TP}
{$PACKRECORDS 1}
{$ENDIF}
type
      realrec = record
         t1 : real;
         t2 : real;
         end;

var
    realfile : file of realrec;
    r : realrec;
begin
    r.t1 := 1.0;
    r.t2 := 2.0;
    assign ( realfile, 'c:\r.rfl' );
    rewrite ( realfile );
    write ( realfile, r );
    close ( realfile );
end.

Any ideas appreciated!

Thanks,


Lowell C. Savage
[hidden email]
505-667-6964 (office/msg)
360-961-8965 (cell/msg)
505-667-4341 (shared fax)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Turbo Pascal/legacy data file issue.

Florian Klaempfl-2
Lowell C. Savage wrote:

> Has anyone come up with a set of routines for converting between Turbo
> Pascal's 6-byte "real" format and FPC's real number format?

http://www.freepascal.org/docs-html/rtl/system/real2double.html

>
> I am trying to use FPC to update a legacy TP 5.5 program.  I've got most
> of the "major" issues solved and am now finding that I'm having trouble
> reading legacy data files.  Many of these data file are "file of XXXRec"
> where "XXXRec" is a rather large and complex Record containing strings,
> integers, bytes, enumerated types, and reals.
>
> My problem is that I am going to need to be able to read these existing
> files (without modification) into the new version of the program.
>
> I've been able to use the "{$PACKRECORDS 1}" and "{$PACKENUMS 1}"
> directives to take care of everything else.  But now I realize that
> Turbo Pascal used a 6-byte real representation while FPC uses either a 4
> or 8-bit representation.
>
> It appears that I'm going to need to make some kind of a special type,
> perhaps a packed record with a "byte", a "smallint" and a 4-byte
> "longword".  Then, I read this value from the existing file and convert
> it into a "real".  Then, when I want to write the file (or another file)
> I convert back to this record type when I fill the record I'm going to
> write.
>
> Here's a simple program to demonstrate the issue.  In Turbo Pascal 5.5
> (Downloaded from http://bdn.borland.com/article/0,1410,20803,00.html)
> this code generates a 12-byte file.  FPC generates a 16-byte file.
> (Actually, the preprocessor directives shown appear to have no effect on

What effect should it have?

> this code--not complaining since the docs don't make it appear that it
> should, just pointing it out.)

The 6 byte real isn't supported by fpc because it isn't handled by the
fpu and thus deadly slow. For maybe 12 years, every new PC has an fpu.

>
> Program testrec;
> {$IFDEF FPC}
> {$MODE TP}
> {$PACKRECORDS 1}
> {$ENDIF}
> type
>      realrec = record
>         t1 : real;
>         t2 : real;
>         end;
>
> var
>    realfile : file of realrec;
>    r : realrec;
> begin
>    r.t1 := 1.0;
>    r.t2 := 2.0;
>    assign ( realfile, 'c:\r.rfl' );
>    rewrite ( realfile );
>    write ( realfile, r );
>    close ( realfile );
> end.
>
> Any ideas appreciated!
>
> Thanks,
>
>
> Lowell C. Savage
> [hidden email]
> 505-667-6964 (office/msg)
> 360-961-8965 (cell/msg)
> 505-667-4341 (shared fax)
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Turbo Pascal/legacy data file issue.

Lowell C. Savage
In reply to this post by Lowell C. Savage
Well, I found a "Real2Double" function in the System unit that converts
from an old TP 6-byte "real" to an 8-byte double.  (Guess I should have
looked a little harder, there.)  But I'm not seeing anything going the
other way.  Anyone?

Thanks,

Lowell
At 12:56 PM 9-19-05, Lowell C. Savage wrote:

>Has anyone come up with a set of routines for converting between Turbo
>Pascal's 6-byte "real" format and FPC's real number format?
>
>I am trying to use FPC to update a legacy TP 5.5 program.  I've got most
>of the "major" issues solved and am now finding that I'm having trouble
>reading legacy data files.  Many of these data file are "file of XXXRec"
>where "XXXRec" is a rather large and complex Record containing strings,
>integers, bytes, enumerated types, and reals.
>
>My problem is that I am going to need to be able to read these existing
>files (without modification) into the new version of the program.
>
>I've been able to use the "{$PACKRECORDS 1}" and "{$PACKENUMS 1}"
>directives to take care of everything else.  But now I realize that Turbo
>Pascal used a 6-byte real representation while FPC uses either a 4 or
>8-bit representation.
>
>It appears that I'm going to need to make some kind of a special type,
>perhaps a packed record with a "byte", a "smallint" and a 4-byte
>"longword".  Then, I read this value from the existing file and convert it
>into a "real".  Then, when I want to write the file (or another file) I
>convert back to this record type when I fill the record I'm going to write.
>
>Here's a simple program to demonstrate the issue.  In Turbo Pascal 5.5
>(Downloaded from http://bdn.borland.com/article/0,1410,20803,00.html) this
>code generates a 12-byte file.  FPC generates a 16-byte file.  (Actually,
>the preprocessor directives shown appear to have no effect on this
>code--not complaining since the docs don't make it appear that it should,
>just pointing it out.)
>
>Program testrec;
>{$IFDEF FPC}
>{$MODE TP}
>{$PACKRECORDS 1}
>{$ENDIF}
>type
>      realrec = record
>         t1 : real;
>         t2 : real;
>         end;
>
>var
>    realfile : file of realrec;
>    r : realrec;
>begin
>    r.t1 := 1.0;
>    r.t2 := 2.0;
>    assign ( realfile, 'c:\r.rfl' );
>    rewrite ( realfile );
>    write ( realfile, r );
>    close ( realfile );
>end.
>
>Any ideas appreciated!
>
>Thanks,
>
>Lowell C. Savage
>[hidden email]
>505-667-6964 (office/msg)
>360-961-8965 (cell/msg)
>505-667-4341 (shared fax)

Lowell C. Savage
[hidden email]
505-667-6964 (office/msg)
360-961-8965 (cell/msg)
505-667-4341 (shared fax)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Turbo Pascal/legacy data file issue.

Lowell C. Savage
In reply to this post by Lowell C. Savage
What I would still like to see is a "Double2Real" which goes in the
opposite direction of the "Real2Double".  That way, I can read the data
from the existing files and then save new data back to the same files.  The
loss of precision is not important since the numbers we are using have
limitations on their precision that are the limiting factor (they could
probably be "singles" without any trouble--except that then they wouldn't
be compatible with the data files.  And performance isn't really an issue
since I'll do any calculations as doubles (native on x86 platform).

Thanks,

Lowell

Florian Klaempfl <[hidden email]> wrote, in part:
>Lowell C. Savage wrote:
>
> > Has anyone come up with a set of routines for converting between Turbo
> > Pascal's 6-byte "real" format and FPC's real number format?
>
>http://www.freepascal.org/docs-html/rtl/system/real2double.html

Thanks.  My apologies for not finding it earlier myself.

> > Here's a simple program to demonstrate the issue.  In Turbo Pascal 5.5
> > (Downloaded from http://bdn.borland.com/article/0,1410,20803,00.html)
> > this code generates a 12-byte file.  FPC generates a 16-byte file.
> > (Actually, the preprocessor directives shown appear to have no effect on
>
>What effect should it have?

I would like it to have the same effect whether compiled under Turbo Pascal
5.5 or under FPC.  In both cases, it should write out a 12-byte file.  I
don't mind if I have to put in a bunch of ifdefs to define "real48" and
dummy "Double2Real" functions for TP or some such and redo the assignments
to call "Double2Real".  In other words, the code can change--but the data
(and data format) is forever.  :-)

> > this code--not complaining since the docs don't make it appear that it
> > should, just pointing it out.)
>
>The 6 byte real isn't supported by fpc because it isn't handled by the
>fpu and thus deadly slow. For maybe 12 years, every new PC has an fpu.


Heavens no!  I don't want to do !!CALCULATIONS!! with the 6-byte reals.  I
just want to be able to read and store them in the existing files.

> > Program testrec;
> > {$IFDEF FPC}
> > {$MODE TP}
> > {$PACKRECORDS 1}
> > {$ENDIF}
> > type
> >      realrec = record
> >         t1 : real;
> >         t2 : real;
> >         end;
> >
> > var
> >    realfile : file of realrec;
> >    r : realrec;
> > begin
> >    r.t1 := 1.0;
> >    r.t2 := 2.0;
> >    assign ( realfile, 'c:\r.rfl' );
> >    rewrite ( realfile );
> >    write ( realfile, r );
> >    close ( realfile );
> > end.

Lowell C. Savage
[hidden email]
505-667-6964 (office/msg)
360-961-8965 (cell/msg)
505-667-4341 (shared fax)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: Turbo Pascal/legacy data file issue.

Jan Ruzicka
I think basic reference information you may be looking for is on page
http://www.merlyn.demon.co.uk/pas-type.htm
------------------------------------------------------------------
real2double from rtl/inc/genmath.inc
------------------------------------------------------------------
     function real2double(r : real48) : double;

       var
          res : array[0..7] of byte;
          exponent : word;

       begin
          { copy mantissa }
          res[0]:=0;
          res[1]:=r[1] shl 5;
          res[2]:=(r[1] shr 3) or (r[2] shl 5);
          res[3]:=(r[2] shr 3) or (r[3] shl 5);
          res[4]:=(r[3] shr 3) or (r[4] shl 5);
          res[5]:=(r[4] shr 3) or (r[5] and $7f) shl 5;
          res[6]:=(r[5] and $7f) shr 3;

          { copy exponent }
          { correct exponent: }
          exponent:=(word(r[0])+(1023-129));
          res[6]:=res[6] or ((exponent and $f) shl 4);
          res[7]:=exponent shr 4;

          { set sign }
          res[7]:=res[7] or (r[5] and $80);
          real2double:=double(res);
       end;
------------------------------------------------------------------
double2real by just mechanically reversed operations
------------------------------------------------------------------
     function double2real(d : double) : real48;

       var
          res : real48;
          exponent : word;

       begin
          { copy mantissa }

          res[0]:=0;
          res[1]:=(d[2] shl 3) or (d[1] shr 5);
          res[2]:=(d[3] shl 3) or (d[2] shr 5);
          res[3]:=(d[4] shl 3) or (d[3] shr 5);
          res[4]:=(d[5] shl 3) or (d[4] shr 5);
          res[5]:=((d[6] and $f) shl 3) or (d[5] shr 5);

          { copy exponent }
          { correct exponent: }
          exponent:= ((d[7] and $7f) shl 4) or ((d[6] shr 4) and $f);
          exponent:= exponent +129-1023;
          res[0]:= exponent and $ff;

          { set sign }
          res[5]:=res[5] or (d[7] and $80);
          double2real:=res;
       end;
------------------------------------------------------------------
The code above will probably not compile as I use indexes of bytes
bytes on type double.
I don't have a working compiler at this moment.
(FPC is not compiling on OSX)
Would this help you?
Could you write some tests to verify correctness?

Jan

On Sep 20, 2005, at 12:14, Lowell C. Savage wrote:

> What I would still like to see is a "Double2Real" which goes in the
> opposite direction of the "Real2Double".  That way, I can read the
> data from the existing files and then save new data back to the same
> files.  The loss of precision is not important since the numbers we
> are using have limitations on their precision that are the limiting
> factor (they could probably be "singles" without any trouble--except
> that then they wouldn't be compatible with the data files.  And
> performance isn't really an issue since I'll do any calculations as
> doubles (native on x86 platform).
>
> Thanks,
>
> Lowell
>
> Florian Klaempfl <[hidden email]> wrote, in part:
>> Lowell C. Savage wrote:
>>
>> > Has anyone come up with a set of routines for converting between
>> Turbo
>> > Pascal's 6-byte "real" format and FPC's real number format?
>>
>> http://www.freepascal.org/docs-html/rtl/system/real2double.html
>
> Thanks.  My apologies for not finding it earlier myself.
>
>> > Here's a simple program to demonstrate the issue.  In Turbo Pascal
>> 5.5
>> > (Downloaded from
>> http://bdn.borland.com/article/0,1410,20803,00.html)
>> > this code generates a 12-byte file.  FPC generates a 16-byte file.
>> > (Actually, the preprocessor directives shown appear to have no
>> effect on
>>
>> What effect should it have?
>
> I would like it to have the same effect whether compiled under Turbo
> Pascal 5.5 or under FPC.  In both cases, it should write out a 12-byte
> file.  I don't mind if I have to put in a bunch of ifdefs to define
> "real48" and dummy "Double2Real" functions for TP or some such and
> redo the assignments to call "Double2Real".  In other words, the code
> can change--but the data (and data format) is forever.  :-)
>
>> > this code--not complaining since the docs don't make it appear that
>> it
>> > should, just pointing it out.)
>>
>> The 6 byte real isn't supported by fpc because it isn't handled by the
>> fpu and thus deadly slow. For maybe 12 years, every new PC has an fpu.
>
>
> Heavens no!  I don't want to do !!CALCULATIONS!! with the 6-byte
> reals.  I just want to be able to read and store them in the existing
> files.
>
>> > Program testrec;
>> > {$IFDEF FPC}
>> > {$MODE TP}
>> > {$PACKRECORDS 1}
>> > {$ENDIF}
>> > type
>> >      realrec = record
>> >         t1 : real;
>> >         t2 : real;
>> >         end;
>> >
>> > var
>> >    realfile : file of realrec;
>> >    r : realrec;
>> > begin
>> >    r.t1 := 1.0;
>> >    r.t2 := 2.0;
>> >    assign ( realfile, 'c:\r.rfl' );
>> >    rewrite ( realfile );
>> >    write ( realfile, r );
>> >    close ( realfile );
>> > end.
>
> Lowell C. Savage
> [hidden email]
> 505-667-6964 (office/msg)
> 360-961-8965 (cell/msg)
> 505-667-4341 (shared fax)
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: Turbo Pascal/legacy data file issue.

Jan Ruzicka
In reply to this post by Lowell C. Savage
Reading the previously mentioned page closely I found section that
contains conversion functions.

http://www.merlyn.demon.co.uk/programs/floatval.pas

The procedure EightToSix is probably what you are looking for


Jan

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re[2]: Turbo Pascal/legacy data file issue.

Ivan Shikhalev
In reply to this post by Florian Klaempfl-2
> The 6 byte real isn't supported by fpc because it isn't handled by the
> fpu and thus deadly slow. For maybe 12 years, every new PC has an fpu.

AFAIK, FPC 2.0 supports the Real48 type... Isn't it?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: Turbo Pascal/legacy data file issue.

Arne Hanssen
In reply to this post by Lowell C. Savage
Thus spoke Lowell C. Savage ([hidden email]):

> At 12:56 PM 9-19-05, Lowell C. Savage wrote:
> >Has anyone come up with a set of routines for converting between Turbo
> >Pascal's 6-byte "real" format and FPC's real number format?
>
> Well, I found a "Real2Double" function in the System unit that converts
> from an old TP 6-byte "real" to an 8-byte double.  (Guess I should have
> looked a little harder, there.)  But I'm not seeing anything going the
> other way.  Anyone?

If this is Windows (or OS/2) you could use Virtual Pascal to build
a conversion program.  Even if VP is "dead" I think you still can
get it from www.vpascal.com.

--
Vennlig hilsen / Best regards      |\     ___,,--,        _
Arne Hanssen, Senja, Norway        /,`--''        \-,,__,'/
http://www.tuxic.net/             |,4   ) )_    ) /~-----'
---------------------------------'---^~(_/-_)--(_/_)-------
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

single application instance

josepascual (almudi)
In reply to this post by Ivan Shikhalev
Hi,

How can avoid to run my program more than once?

thank you in advanced


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: single application instance

Alexey Pavluchenko
Hello Jose,

Thursday, September 22, 2005, 1:20:48 PM, you wrote:

JP> How can avoid to run my program more than once?

I suppose you wanted to ask "how can I allow only one instance of my
program running under Win32". Correct me if I'm wrong. If I'm right,
then you may do it like this: check for named mutex with the name
unique to your program, if it does not exist then create it, if it
does then terminate the program. The following code is from APPINIT
unit written by Marc Batchelor:

=== cut ===
procedure InitInstance;
begin
  { Check to see if the mutex is already there }
  InstanceMutexHandle := OpenMutex(MUTEX_ALL_ACCESS, false,
    @UniqueApplicationString[1]);
  if InstanceMutexHandle = 0 then
  begin
    { This is the first instance }
    InstanceMutexHandle := CreateMutex(nil, false,
      @UniqueApplicationString[1]);
    { Error checking to see if anyone beat us... }
    if InstanceMutexHandle = 0 then
      IsFirstInstance := false
    else
      IsFirstInstance := true;
  end
  else
    IsFirstInstance := false;
end;
=== cut ===

UniqueApplicationString in the above example is a shortstring, if you
use ansistring then you don't need '@' operator and '[1]' index, just
typecast it to pchar. The string should be unique system-wide so it is
probably best to generate it based on some pseudo-random numbers.

--
Best regards,
 Alexey


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: single application instance

josepascual (almudi)
Hi Alexey,

thank you for your answer, I'm thinking about some portable solution for
win32 and linux?
How can I also do it in linux?

tia!
best regards


> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre de
> Alexey Pavluchenko
> Enviado el: viernes, 23 de septiembre de 2005 10:35
> Para: FPC-Pascal users discussions
> Asunto: Re: [fpc-pascal] single application instance
>
>
> Hello Jose,
>
> Thursday, September 22, 2005, 1:20:48 PM, you wrote:
>
> JP> How can avoid to run my program more than once?
>
> I suppose you wanted to ask "how can I allow only one
> instance of my program running under Win32". Correct me if
> I'm wrong. If I'm right, then you may do it like this: check
> for named mutex with the name unique to your program, if it
> does not exist then create it, if it does then terminate the
> program. The following code is from APPINIT unit written by
> Marc Batchelor:
>
> === cut ===
> procedure InitInstance;
> begin
>   { Check to see if the mutex is already there }
>   InstanceMutexHandle := OpenMutex(MUTEX_ALL_ACCESS, false,
>     @UniqueApplicationString[1]);
>   if InstanceMutexHandle = 0 then
>   begin
>     { This is the first instance }
>     InstanceMutexHandle := CreateMutex(nil, false,
>       @UniqueApplicationString[1]);
>     { Error checking to see if anyone beat us... }
>     if InstanceMutexHandle = 0 then
>       IsFirstInstance := false
>     else
>       IsFirstInstance := true;
>   end
>   else
>     IsFirstInstance := false;
> end;
> === cut ===
>
> UniqueApplicationString in the above example is a
> shortstring, if you use ansistring then you don't need '@'
> operator and '[1]' index, just typecast it to pchar. The
> string should be unique system-wide so it is probably best to
> generate it based on some pseudo-random numbers.
>
> --
> Best regards,
>  Alexey
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fp> c-pascal
>
>
> __________ Información de NOD32, revisión 1.1230
> (20050922) __________
>
> Este mensaje ha sido analizado con  NOD32 antivirus system
http://www.nod32.com


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: single application instance

Matt Emson
> How can I also do it in linux?

Use semaphores. There is a semaphore implementation for LINUX, Windows, BeOS
and probably most other Unices. Certainly, any platform that conforms to
POSIX and/or PThreads will have a semaphore implementation.

The mechanics will be different - the idea will be universal.

M

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: single application instance

Micha Nelissen
On Fri, 23 Sep 2005 17:16:36 +0100
"Matt Emson" <[hidden email]> wrote:

> > How can I also do it in linux?
>
> Use semaphores. There is a semaphore implementation for LINUX, Windows, BeOS

Semaphores <> Mutexes. Semaphores do not always have names and are not
system-wide.

Micha
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: single application instance

Marco van de Voort
In reply to this post by Matt Emson
> > How can I also do it in linux?
>
> Use semaphores. There is a semaphore implementation for LINUX, Windows, BeOS
> and probably most other Unices. Certainly, any platform that conforms to
> POSIX and/or PThreads will have a semaphore implementation.
>
> The mechanics will be different - the idea will be universal.

For *nix it is in unit ipc.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: single application instance

Matt Emson
In reply to this post by Micha Nelissen
> Semaphores <> Mutexes. Semaphores do not always have names and are not
> system-wide.

In my experience, its the other way round. Semaphores are system wide/cross
process. Admittedly, they are not always named though.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE: single application instance

josepascual (almudi)
any example of implementation for semaphore in linux which I can use to
know if there is
some instance of my program already running?

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre de
> Matt Emson
> Enviado el: viernes, 23 de septiembre de 2005 18:53
> Para: FPC-Pascal users discussions
> Asunto: Re: [fpc-pascal] single application instance
>
>
> > Semaphores <> Mutexes. Semaphores do not always have names
> and are not
> > system-wide.
>
> In my experience, its the other way round. Semaphores are
> system wide/cross process. Admittedly, they are not always
> named though.
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fp> c-pascal
>
>
> __________ Información de NOD32, revisión 1.1230
> (20050922) __________
>
> Este mensaje ha sido analizado con  NOD32 antivirus system
http://www.nod32.com


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal