Re: [fpc-devel] Re: File Dates
On Sun, 30 Jan 2005, Jeff Pohlmeyer wrote: > > > unit libmagic; > > > Can we include this in the FPC packages ? I think it would be useful. > > Michael. > > It's okay with me, I'm always glad to contribute what I can to FPC. > - Jeff Thank you. I'll add dynamical loading of the libmagic library. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: File Dates
> > unit libmagic; > Can we include this in the FPC packages ? I think it would be useful. > Michael. It's okay with me, I'm always glad to contribute what I can to FPC. - Jeff . __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMT compatibility
On Sun, 30 Jan 2005, Marco van de Voort wrote:
> > // Call C++ function and pass to it our "special" interface
> > Result := D3DXLoadMeshHierarchyFromX_FPC_{$}(Filename, MeshOptions,
> > pD3DDevice, AllocI, pUserDataLoader, ppFrameHierarchy, ppAnimController);
> >
> > Dec(PInteger(AllocI)^, $C); // Patch interface VMT - BACK
> > end;
> >
> > But I really want FPC be compatible with Delphi in this situation.
>
> If I recall correctly, this was all done because the linker had problems with
> symbols with negative offsets.
This is correct. In combination with smartlinking, I think.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMT compatibility
Delphi and FreePascal simplest interfaces already includes IUnknown. So using raw interfaces is incompatible here too. No. You could try to use CORBA interfaces, they don't have IInterface (or IUnknown) as the parent. There is a compiler switch for this. Thanks, I'll look at it. Seems really better solution. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] File Dates
On Sun, 30 Jan 2005, DrDiettrich wrote: > Michael Van Canneyt wrote: > > > > FPC defines 1900-1-1 as the start date, whereas Delphi defines > > > 1899-12-30 as the start date - note: neither 1900 nor dec. 31! > > > This requires different constants for converting a Unix date into > > > TDateTime, or portable procedures. What's the suggested way for such > > > conversions? > > > > There are routines which change file dates as reported by the various > > file functions to TDateTime, so you don't need to worry about this. > > The file functions are not applicable to the information stored in > archive files. Archives can contain Unix or MSDOS specific file > information, that has to be handled on all platforms, or better: file > systems, where the files are to be extracted. Abbrevia implements e.g. > procedures to map between Unix and DOS file attributes. In Delphi a > FileTimeToLocalFileTime procedure only is supported as a Windows API > function, not available on Linux. NTFS is a bit weird regarding filetimes; But I don't know whether we should concern ourselves with filesystem details ? > > > > > It would be nice to apply the file attributes just when a file is > > > created, instead of after closing an file, but I have no idea whether > > > this will be possible on all platforms? > > > > Consider this a no, this is the safest; If you do it at file open, then > > the system may change your written timestamp as you write to the file. > > Your're right, at least the timestamp(s) must be updated after the file > has been closed. > > > > The only file with such info is mime.types or mime.cap in /etc. > > Of course, KDE and GNOME have their own copies of this file for internal > > purposes. > > What I saw was not restricted to MIME, but it might have been KDE > specific. That's what I was referring too... > > > > > appreciate some assistance for the implementation of the Unix specific > > > procedures, and for testing of course. Hands up somebody out there? > > > > Just tell me what you need, and I'll be glad to implement it. > > As far as I remember, you were going to hide all platform specific stuff > > in a separate file anyway, insofar as it is not yet in sysutils. > > IMO it would make sense to have an Unix "stat" record available on all > platforms. This record then can be filled with the Unix-style file > information in an archive, and then has to be applied to the extracted > file, on any platform. Similarly it should be possible to initialize it > with the information about an existing file, on any platform or file > system, for storage of the applicable information in an archive. As > mentioned above, a translation between the Unix permissions and FAT file > attributes can be borrowed from Abbrevia. A more general procedure would > be nice, that can translate the Unix and FAT file attributes for use on > the actual target platform, as far as supported by fpc. This is a tricky issue. I'm not sure what path should be followed here. > > Next comes the conversion of file names, what migth be tricky for MSDOS. > That's why I would not support 16-bit DOS now - does somebody see a need > for such support? Or would you implement according conversions for DOS? No. It's a mess. There is some support present for 8.3 in the FPC sources, but new things will not be added. > > My fileutil unit currently is 13 KB, in the Windows version, but I'll > have to add some more comments to it. Then I can send you this unit, or > can I simply post it here as information for everybody? Send it private. Big files are not allowed on the list, although I don't know the exact limit. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: File Dates
On Sat, 29 Jan 2005, Jeff Pohlmeyer wrote:
>
> > AFAIR Unix has some kind of registry for file types, based on file
> > extensions and characteristic bytes at the begin of an file. Does
> > somebody know more about that registry, so that it could be integrated
> > into the intended registry for archive handlers?
>
>
> =
Can we include this in the FPC packages ? I think it would be useful.
Michael.
>
> unit libmagic;
> interface
> {$PACKRECORDS C}
> {$LINKLIB magic}
> {$LINKLIB c}
>
> const
> MAGIC_NONE = $000;
> MAGIC_DEBUG = $001;
> MAGIC_SYMLINK= $002;
> MAGIC_COMPRESS = $004;
> MAGIC_DEVICES= $008;
> MAGIC_MIME = $010;
> MAGIC_CONTINUE = $020;
> MAGIC_CHK= $040; // naming conflict ( was MAGIC_CHECK )
> MAGIC_PRESERVE_ATIME = $080;
> MAGIC_RAW= $100;
> MAGIC_ERR= $200; // naming conflict ( was MAGIC_ERROR )
>
> type
> size_t = dword;
>
> magic_set = record
> {opaque structure}
> end;
> magic_t = ^magic_set;
>
> function magic_open(flags:LongInt):magic_t;cdecl;external;
> function magic_file(cookie:magic_t; filename:pChar):pChar;cdecl;external;
> function magic_error(cookie:magic_t):pChar;cdecl;external;
> function magic_setflags(cookie:magic_t; flags:LongInt):LongInt;cdecl;external;
> function magic_load(cookie:magic_t; filename:pChar):LongInt;cdecl;external;
> function magic_compile(cookie:magic_t; filename:pChar):LongInt;cdecl;external;
> function magic_check(cookie:magic_t; filename:pChar):LongInt;cdecl;external;
> function magic_errno(cookie:magic_t):LongInt;cdecl;external;
> procedure magic_close(cookie:magic_t);cdecl;external;
> function magic_buffer( cookie:magic_t;
>buffer:pointer; buflen:size_t):pChar;cdecl;external;
>
>
> implementation
> end.
>
> =
>
> program testmagic;
>
> uses strings, libmagic;
>
> var
> magic: magic_t;
>
> begin
> if ( paramcount = 1 ) then begin
> magic:=magic_open( MAGIC_SYMLINK or MAGIC_MIME );
> magic_load(magic, nil);
> WriteLn(magic_file(magic, argv[1]));
> magic_close(magic);
> end else WriteLn(StdErr, 'Usage: testmagic ');
> end.
>
>
> =
>
>
> Requires "file" --version >= 4.0
>
>
> See also:
> http://directory.fsf.org/file.html
> http://prdownloads.sourceforge.net/gnuwin32/file-4.12-lib.zip?download
>
>
>
>
>
> .
>
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ___
> 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] VMT compatibility
On Sun, 30 Jan 2005, Alexey Barkovoy wrote: > - Original Message - > From: "Florian Klaempfl" <[EMAIL PROTECTED]> > > >> For example "DECLARE_INTERFACE_(IClassFactory, IUnknown)" in C++ is > >> expanded > >> to "struct FAR IClassFactory : public IUnknown", so really public parts of > >> VMT (with positive offset) are always [should be] compatible. Surely we > >> can't > >> talk about FULL compatibility of classes, but exposing "interfaces" to > >> other > >> languages should be possible. > > > > Use raw interfaces for such a purpose. > > Problem is here: > > >> Problem here is what I'm forced to use some these COM incompatibe > >> "interfaces" exposed by MS programmers in DirectX API. These interfaces > >> look > >> like real COM interfaces but without IUnknown embedded. In Delphi I can use > >> them just by creating abstract class just like in C++, but in FPC it's > >> impossible to do so. And I've seen other reports when people were forced to > >> use similiar cripped interfaces exposed by C++ programmers. So it's the > >> real > >> problem not just artificial one. > > Delphi and FreePascal simplest interfaces already includes IUnknown. So using > raw interfaces is incompatible here too. No. You could try to use CORBA interfaces, they don't have IInterface (or IUnknown) as the parent. There is a compiler switch for this. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMT compatibility
> // Call C++ function and pass to it our "special" interface
> Result := D3DXLoadMeshHierarchyFromX_FPC_{$}(Filename, MeshOptions,
> pD3DDevice, AllocI, pUserDataLoader, ppFrameHierarchy, ppAnimController);
>
> Dec(PInteger(AllocI)^, $C); // Patch interface VMT - BACK
> end;
>
> But I really want FPC be compatible with Delphi in this situation.
If I recall correctly, this was all done because the linker had problems with
symbols with negative offsets.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMT compatibility
- Original Message -
From: "Florian Klaempfl" <[EMAIL PROTECTED]>
For example "DECLARE_INTERFACE_(IClassFactory, IUnknown)" in C++ is expanded
to "struct FAR IClassFactory : public IUnknown", so really public parts of
VMT (with positive offset) are always [should be] compatible. Surely we can't
talk about FULL compatibility of classes, but exposing "interfaces" to other
languages should be possible.
Use raw interfaces for such a purpose.
Problem is here:
Problem here is what I'm forced to use some these COM incompatibe
"interfaces" exposed by MS programmers in DirectX API. These interfaces look
like real COM interfaces but without IUnknown embedded. In Delphi I can use
them just by creating abstract class just like in C++, but in FPC it's
impossible to do so. And I've seen other reports when people were forced to
use similiar cripped interfaces exposed by C++ programmers. So it's the real
problem not just artificial one.
Delphi and FreePascal simplest interfaces already includes IUnknown. So using
raw interfaces is incompatible here too.
Actually I have working solution and it's based as you hinted on interface
feature of object pascal, but after quering interface a have to patch object
instance so pointer to VMT start pointing above IUnknown part of it. Something
like this:
var
AllocI: ID3DXAllocateHierarchy_Interface;
begin
AllocI:= pAlloc;
// Now patch interface VMT - so it will point to truncated interface (without
IUnknown)
Inc(PInteger(AllocI)^, $C);
// Call C++ function and pass to it our "special" interface
Result := D3DXLoadMeshHierarchyFromX_FPC_{$}(Filename, MeshOptions,
pD3DDevice, AllocI, pUserDataLoader, ppFrameHierarchy, ppAnimController);
Dec(PInteger(AllocI)^, $C); // Patch interface VMT - BACK
end;
But I really want FPC be compatible with Delphi in this situation.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMT compatibility
Alexey Barkovoy wrote: - Original Message - From: "Michael Van Canneyt" <[EMAIL PROTECTED]> Delphi is compatible at least with Borland C++ and MS VC++. And taking in accout how COM intefaces are implemented in C++ (I'm supposing here all C++ compilers support the same syntax) - each C++ compiler supporting MS way to declare COM interfaces has compatible VMT layout. That would be true only for interfaces, not for straight VMTs ? And Delphi's VMT's are not compatible with GCC's; At least, kylix cannot use GCC classes. I'm not even sure they are compatible with the ones from MS Visual C++; Well, interfaces are really C++ abstract classes. COM model adds some bell and whistles above that (including IUnknown that is integrated in object pascal language interfaces). For example "DECLARE_INTERFACE_(IClassFactory, IUnknown)" in C++ is expanded to "struct FAR IClassFactory : public IUnknown", so really public parts of VMT (with positive offset) are always [should be] compatible. Surely we can't talk about FULL compatibility of classes, but exposing "interfaces" to other languages should be possible. Use raw interfaces for such a purpose. - Original Message - From: "DrDiettrich" <[EMAIL PROTECTED]> The layout of C++ classes is compiler specific. In so far BCB and MSVC may be compatible, or MSC and BC, but only for specific compiler versions. OPL (fpc, Delphi...) classes are different from C++ classes, not only in the VMT layout, but also in other significant details. That's why BCB provides special support for TObject based classes, but these classes still are different from the C++ classes. Yes, VMT implementation of private fields are different in C++ and pascal. And public parts of VMT are compatible for ALL versions of MS and Borland C++ compilers! COM (ActiveX...) is not related to C++, it defines another object model, data types, and class layout. This is totally incorrect statement. Inprocess COM is heavy relayed on C++ abstract classes. I'm not talking here about ActiveX (it's really just a framework above COM), marshalling, etc. If you really need portable classes, then you should use COM/ActiveX on Windows, or possibly CORBA for more platform independence. Though I don't know whether fpc supports CORBA? Problem here is what I'm forced to use some these COM incompatibe "interfaces" exposed by MS programmers in DirectX API. These interfaces look like real COM interfaces but without IUnknown embedded. In Delphi I can use them just by creating abstract class just like in C++, but in FPC it's impossible to do so. And I've seen other reports when people were forced to use similiar cripped interfaces exposed by C++ programmers. So it's the real problem not just artificial one. Regards, Alexey Barkovoy ___ 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] VMT compatibility
- Original Message - From: "Michael Van Canneyt" <[EMAIL PROTECTED]> Delphi is compatible at least with Borland C++ and MS VC++. And taking in accout how COM intefaces are implemented in C++ (I'm supposing here all C++ compilers support the same syntax) - each C++ compiler supporting MS way to declare COM interfaces has compatible VMT layout. That would be true only for interfaces, not for straight VMTs ? And Delphi's VMT's are not compatible with GCC's; At least, kylix cannot use GCC classes. I'm not even sure they are compatible with the ones from MS Visual C++; Well, interfaces are really C++ abstract classes. COM model adds some bell and whistles above that (including IUnknown that is integrated in object pascal language interfaces). For example "DECLARE_INTERFACE_(IClassFactory, IUnknown)" in C++ is expanded to "struct FAR IClassFactory : public IUnknown", so really public parts of VMT (with positive offset) are always [should be] compatible. Surely we can't talk about FULL compatibility of classes, but exposing "interfaces" to other languages should be possible. - Original Message - From: "DrDiettrich" <[EMAIL PROTECTED]> The layout of C++ classes is compiler specific. In so far BCB and MSVC may be compatible, or MSC and BC, but only for specific compiler versions. OPL (fpc, Delphi...) classes are different from C++ classes, not only in the VMT layout, but also in other significant details. That's why BCB provides special support for TObject based classes, but these classes still are different from the C++ classes. Yes, VMT implementation of private fields are different in C++ and pascal. And public parts of VMT are compatible for ALL versions of MS and Borland C++ compilers! COM (ActiveX...) is not related to C++, it defines another object model, data types, and class layout. This is totally incorrect statement. Inprocess COM is heavy relayed on C++ abstract classes. I'm not talking here about ActiveX (it's really just a framework above COM), marshalling, etc. If you really need portable classes, then you should use COM/ActiveX on Windows, or possibly CORBA for more platform independence. Though I don't know whether fpc supports CORBA? Problem here is what I'm forced to use some these COM incompatibe "interfaces" exposed by MS programmers in DirectX API. These interfaces look like real COM interfaces but without IUnknown embedded. In Delphi I can use them just by creating abstract class just like in C++, but in FPC it's impossible to do so. And I've seen other reports when people were forced to use similiar cripped interfaces exposed by C++ programmers. So it's the real problem not just artificial one. Regards, Alexey Barkovoy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
