Hi,
It seems that CG plans to implement an non BSTR widestring type for win32: http://groups.google.ch/group/borland.public.delphi.non-technical/msg/7caeced42f1934a4?hl=en&

The introduced string handling for the "Unicode VCL" is equivalent to the string handling in MSEgui BTW.

Martin

Op Sat, 16 Jun 2007, schreef Martin Schreiber:

Noted. As COM incompatibilty seems preferable over not working widestrings, shall I disable the winlikewidestring in 2.1.5?

Can someone reply Allan Bauer about using ptrint, and better, ptruint (explain pitfalls). It seems I have been banned from that newsgroup yesterday, without any apparent reason :(

Daniël

I would appreciate very much. If you can do so, I could restart the testing and debugging of FPC 2.2.

Can someone reply Allan Bauer about using ptrint, and better, ptruint (explain pitfalls). It seems I have been banned from that newsgroup yesterday, without any apparent reason :(

Please post on this list what you want to write to him, I'll try to feed forward.

Martin

Op Sat, 16 Jun 2007, schreef Martin Schreiber:

I made the change, could you please test for any problems, as we are really close to 2.2.0.

Something like this?

"Note that casting pointers to signed values is often a bad idea, since the virtual address space on a 32-bit system is often 3 gigabytes, i.e. pointers can have values between $80000000..$c0000000. A signed type causes trouble in pointer value comparisons (like if p>q then).

In Free Pascal there already exist two types ptrint and ptruint (signed and unsigned) for this purpose, you might want to recycle them especially as many people are currently using constructions like:

{$ifndef FPC}
type ptruint=longword;
{$endif}

... in order to be able to get their code to work on Win64 using FPC; this will make it easier for people to switch back to Delphi for 64-bit development when it is ultimately released."

Daniël

Widestring remains the COM compatible one AFAICS, and there is a new UnicodeString that maybe has ref counting features. I quote:

"WideString will remain a BSTR for use in interoperating with COM. The good thing is that the conversions between BSTRs and UnicodeStrings is much more simple and straight forward..."

Micha

You mean to let it compile on delphi (win32), while porting the code to win64 using FPC. It would compile on FPC anyway.

Micha

Daniël Mantione wrote

I made the change, could you please test for any problems, as we are really close to 2.2.0.

Thanks, I start to work.

Something like this?

[...]
Posted to delphi.non-tech.

Martin

Op Sat, 16 Jun 2007, schreef Micha Nelissen:

Yes, but this is exactly what many Delphi users are doing at the moment, i.e. component developers like RemObjects, Components4Developers are all porting to FPC in order to support Win64 and/or Linux while the majortity of their users uses Delphi. This might be both to support current users that need Win64 or to prepare themselves; starting the port in 2009 or 2010 might be a little bit late.

So, in 2009 or even 2010 when Delphi for Win64 is released there will be a lot of code running on Win64 using FPC, and making it hard for people to compile such code on Delphi seems like Codegear is asking for trouble.

Daniël

Op Sat, 16 Jun 2007, schreef Daniël Mantione:

It seems it is a mistake after all. Can you reply to Rudy I am getting this message:

441 Feedrule: line 329: Access Denied.

Daniël

MSEide+MSEgui compiles and works with FPC fixes_2_2 on win32 and Linux, thanks a lot!
I found two issues up to now: Mantis 9093 and 9094.

Martin

You're aware of the fact that this breaks a lot of code especially delphi compatible one? (Ole)Variants on windows are probably broken too.

Op Sat, 16 Jun 2007, schreef Florian Klaempfl:

Yes I am. This is an emergency measure; incompatible widestrings are preferable over broken widestrings, which totally blocks the usability of FPC 2.1+ for for Martin. I am fully aware of the consequences; all code which does something with OLE will not function.

Daniël

Not working? Why is widestring not working? Moreover this would rule out getting Delphi (existing Delphi) compatible in the 2.2 series?

I've reverted the change and created a proper fix in 7691. As soon as it proves being good, I merge it.

Op Sat, 16 Jun 2007, schreef Marco van de Voort:

When assigning two records/arrays/whatever type containing a widestring to another the compiler:
* Two pointers are pointing to the same widestring
* One widestring is lost in memory as a memory leak

Florian has written a proper fix.

Daniël

Good, so now we are COM compatible again? This because I am planning to port the OpenOffice bridge.

However that uses COM _and_ packages. (though I hope to get rid of the need for pacakges)

How can it require packages ? Packages are just a distribution tool. The code itself should in no way refer to packages ?

Michael.

I don't exactly know why, but the program doesn't work when you turn packages off. (note that FPC fails in yet another point)

I have to inspect it further, but I suspect he defines an own COM component, which is then registered (which is maybe only possible for a DLL), but at the same time he doesn't really master EXE-DLL communication (using non automated), thus made it a package. The source is quite a mess (Clootie's btw, but earlier work)

That's why I have some hope it can be eliminated.

Sound like a real kludge. Good luck disentangling that one :/

That's why I have some hope it can be eliminated.

Hmmm. COM is a mess.

The openoffice one doubly so, because there is no TLB to import. It's all runtime binding. I had a hell of a time automating it :/

Michael.