Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2001-05

filemode info for fpc docn - was w2000 file opening

7 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Lee, John

thanks for this info...

Yup filemode equals $40 fixes my win 2000 access problem to a win2000 performance log...- I was originally advised to use 0 in [devel]!

IMO one shouldn't need to look at the source...the info below should go into docn, under reset/rewrite + short explanation of filemode 'To open files which may be open and used by other processes filemode can be used. THE DEFAULT SETTING IS ??? It can be set to the following values, dependent on the operating system...'

Don't think filemode does anything under Dos. Does filemode do anything for unix/linux/m68k? What values are appropriate? If so can this be explained too...TIA J

Earlier message 42 lines
-----Original Message----- From: Gabor DEAK JAHN Sent: Thursday, May 10, 2001 03:19 To: Subject: RE: [fpc-pascal]w2000 file opening - was dos approx delay fn that releases cpu At 5/9/01 02:30 PM, you wrote: Jim > I wish I could be more help about the rest of the filemode settings for > Win32, but unfortunately I don't recall where I got that info from. Sorry. From the file Win32.inc: fmShareCompat = $00000000; fmShareExclusive = $10; fmShareDenyWrite = $20; fmShareDenyRead = $30; fmShareDenyNone = $40; If you check out Syswin32.pp from the RTL source (procedure Do_Open), you'll see that the single Filemode value passed on by routines like Reset or Rewrite will not be used directly but dissected into several flags and then fed to the appropriate Win32 routines. I didn't check if every possible value and flag is handled by the FPC RTL or not, but you can always call the Win32 file I/O functions directly, providing whatever flag you want. The MSDN documentation of CreateFile has a description of all flags accepted by Win32. Bye, G�bor ------------------------------------------------------------------- Gabor DEAK JAHN -- Budapest, Hungary. E-mail:

Reply by email

Unknown author
Don't think filemode does anything under Dos.

filemode does have an effect for DOS as well, but the number of modes (and some of the corresponding settings) are different. AAMOF, there are differences for the ioresult return codes from open(), reset(), rewrite(), etc.

Jim

Reply by email

Lee, John

It'd be best if we could have something that's o/s independent... but I accept, based on the comments, that this might be difficult (see my 0.001 euro worth below). Until we can do this tho' my main reason for raising this is to simply document what the choices are for each o/s...& I guess that isn't too difficult.

Maybe instead of trying to adapt things we could just have a normal open (0 as at present) and a 'try to open whatever eg whether file locked or not' value eg as another variable say called, say, force_open, (eg 1) which are same value for all o/s & wouldtherefore be portable...Eg for win32 this could translate to the current filemode vals of 0 and $40, for linux whatever. If users want more sophisticated behaviour we'd tell users to use the appropriate o/s dependent filemode values directly...

From:
Sent: Friday, May 11, 2001 01:24
To:
Subject: Re: filemode info for fpc docn - was w2000 file opening

Marco van de Voort wrote 5 lines
> On Thu, 10 May 2001, Marco van de Voort wrote: > > > > > thanks for this info... > > > > > > > > Yup filemode equals $40 fixes my win 2000 access problem to a

win2000

> > > > performance log...- I was originally advised to use 0 in [devel]! > > > > > > > > IMO one shouldn't need to look at the source...the info below

should go into

> > > > docn, under reset/rewrite + short explanation of filemode 'To open

files

> > > > which may be open and used by other processes filemode can be

used. THE

> > > > DEFAULT SETTING IS ??? It can be set to the following values,

dependent on

Show quoted text 5 lines
> > > > the operating system...' > > > > > > > > Don't think filemode does anything under Dos. > > > > > > It does something under all platforms, just the values it accepts

are

Show quoted text 5 lines
> > > different under each platform. > > > > > > I've added this to my todo list, though. > > > > Do you intend to solve it via a series of constants, or conversion of

the

> > value in the functions that use FileMode? > > > > I don't intend to do anything in the RTL, I plan to mention it in the

docs

Show quoted text 6 lines
> :) > > Do you think this should be treated on a RTL level ? Even Kylix doesn't > do that. (simply not possible, I think) Why not ? We can introduce fmxxx like constants for filemode variable too

on

a per platform basis?

yes, but what are these constants and what if some constant has no meaning on some platform ? fmShareDenyNone or something has no meaning on Linux.

It won't be perfect, but it will make keeping targets source compatible

with

eachother easier.

I know; I haven't really decided for myself what it's going to be.

Michael.

Reply by email

Peter Vreman
Show quoted text 13 lines
It'd be best if we could have something that's o/s independent... but I accept, based on the comments, that this might be difficult (see my 0.001 euro worth below). Until we can do this tho' my main reason for raising this is to simply document what the choices are for each o/s...& I guess that isn't too difficult. Maybe instead of trying to adapt things we could just have a normal open (0 as at present) and a 'try to open whatever eg whether file locked or not' value eg as another variable say called, say, force_open, (eg 1) which are same value for all o/s & wouldtherefore be portable...Eg for win32 this could translate to the current filemode vals of 0 and $40, for linux whatever. If users want more sophisticated behaviour we'd tell users to use the appropriate o/s dependent filemode values directly...

Why do we need a new way? The current filemode values all support opening modes correctly.

The only missing thing for easier accessing are the fm<Mode> constants in the system unit. I don't have tp here so i can't check the tp7 rtl for it. For delphi/kylix they are defined in Sysutils

Reply by email

Jeff Wormsley
to Peter Vreman
PM Peter Vreman wrote 6 lines
Why do we need a new way? The current filemode values all support opening modes correctly. The only missing thing for easier accessing are the fm<Mode> constants in the system unit. I don't have tp here so i can't check the tp7 rtl for it. For delphi/kylix they are defined in Sysutils

In BP7, there is this:

{ File mode magic numbers }

  fmClosed = $D7B0;
  fmInput  = $D7B1;
  fmOutput = $D7B2;
  fmInOut  = $D7B3;

This what you are looking for?

Reply by email

Boci
to Lee, John: It'd be best if we could have something that's o/s independent... but I accept, based on…

Hello!
A long time ago....
I found error on the GTK unit over FreeBSD.
I thinking much more, and I found the solution.
I rewrite in the source of the FreeBSD/GTK unit gtk/gtk.pp and gdk/gdk.pp: gdkdll='gdk' -> gdkdll='gdk12'
and
gtkdll='gtk' -> gtkdll='gtk12'

Please correct this error on the FreePascal 1.0.4/FreeBSD distribution. Thanx : Boci
ps: after this little modification the FreePascal work very well :))))

Reply by email

Stephen Hurd
to Boci

I rewrite in the source of the FreeBSD/GTK unit gtk/gtk.pp and gdk/gdk.pp: gdkdll='gdk' -> gdkdll='gdk12'
and
gtkdll='gtk' -> gtkdll='gtk12'

Actually, this is a common thing on FreeBSD platforms... not unique to FreePascal. What I did was create symlinks.

Reply by email