Yury Sidorov wrote:

Moved to fpc-devel because contains stuff which needs probably more discussion.

The question is if the real command line shouldn't be assigned to the PChar cmdline. If someone wants the unicode command line he should use a WinCE syscall. How is this handled in the GNU port to arm-wince? What type does argv have?

Yes. The windows unit was done this way, however, the GNU headers instead of the MS ones were used.

I will try to generate WinCE units...

From: "Florian Klaempfl"

In GCC for WinCE argv[] is char* and conversions from Unicode to ANSI are performed.
The same conversions can be done in FPC too.

So what way should we go?

1. Leave RTL string types as is (PChar/AnsiString) and perform conversion from Unicode if needed.

2. Define new types PSysChar/SysString to correspond either PChar/AnsiString or PWideChar/WideString depending from OS type.

3. Be avare of UNICODE define and produce fully Unicode RTL if it is defined and ANSI RTL if it is not defined.

Yury Sidorov.

From: "Florian Klaempfl"

Can MS WinCE headers be used for conversion? Or is there copyright problem?

Yury Sidorov.

Yury Sidorov wrote

So what way should we go? 1. Leave RTL string types as is (PChar/AnsiString) and perform conversion from Unicode if needed.

No problem.

2. Define new types PSysChar/SysString to correspond either PChar/AnsiString or PWideChar/WideString depending from OS type.

It's not a good idea to have String as WideString *without* reference counting on WinCE, and Wide or Ansi strings *with* reference counting in other cases.

3. Be avare of UNICODE define and produce fully Unicode RTL if it is defined and ANSI RTL if it is not defined.

As above, exchangable Char and String types only should differ in the character size, not in the automatic handling of string memory (refcount, copy-on-write...).

Does anybody know good reasons for making strings *not* reference counted?
Is this behaviour related to inter-task communication? What about transferring strings from one process to another one, on various platforms?

How do MS compilers handle code written for both Ansi and Unicode environments, and the related data types? How are string arguments (out) handled in Windows API's?
Is this Microsoft way a good model for other platforms?

DoDi

From: "Hans-Peter Diettrich"

I did not say anything about ref-counting in strings. WideStrings are refcounted as well as AnsiStrings.

I meant the following:

In WinCE system unit define:

type
  PSysChar = PWideChar;
  SysString = WideString;

Then modify some OS related RTL variables/functions to use theese PSysChar/SysString types.
For example:

var
  cmdline: PSysChar;
...
function paramstr(l : longint) : SysString;
...

System units for non-unicode OSes will define theese types as:

type
  PSysChar = PChar;
  SysString = AnsiString;

Yury Sidorov.

From: "Hans-Peter Diettrich"

How do MS compilers handle code written for both Ansi and Unicode environments, and the related data types? How are string arguments (out) handled in Windows API's? Is this Microsoft way a good model for other platforms?

MS provides types for strngs/characters which are become differ if UNICODE is defined or not.
For example LPCTSTR is an LPCWSTR if UNICODE is defined, an LPCTSTR otherwise.
Therefore UNICODE define can easily convert MS RTL to unicode and non-unicode versions.

Yury Sidorov.

And for Borland plan always was:

{$IFDEF UNICODE}
  String = WideString;
  Char = WideChar;
{$ELSE}
  String = AnsiString;
  Char = AnsiChar;
{$END}

but seems it will not be realized for some or other reasons.

From: "Alexey Barkovoy"

I think String and Char types must be leaved as is, but new types like SysChar/SysString can be defined for unicode support.

Yury Sidorov.

I would leave it an ansistring. Experience showed that people expect that functions behave on all OSes the same way. Add an additional paramstrw.

From: "Florian Klaempfl"

Ok. All unicode strings will be converted to ansistrings in WinCE RTL.

Yury Sidorov.

Hello,

I found that try...except and try...finally do not work if SysUtils unit is not used (exception handling code is not called).
The attached patch fixes this issue.

Yury Sidorov,

Hello,

I found that try...except and try...finally do not work if SysUtils unit is not used (exception handling code is not called).
The following patch fixes this issue.

Index: system.inc
===================================================================
--- system.inc (revision 594)
+++ system.inc (working copy)
@@ -674,7 +674,10 @@
 Procedure HandleErrorAddrFrame (Errno : longint;addr,frame :
Pointer);[public,alias:'FPC_BREAK_ERROR'];
 begin
   If pointer(ErrorProc)Nil then
-    ErrorProc(Errno,addr,frame);
+    ErrorProc(Errno,addr,frame)
+  else
+    if frame  nil then
+      raise TObject(nil) at addr,frame;
   errorcode:=word(Errno);
   erroraddr:=addr;
   errorbase:=frame;

By the way, messages with attachment are not posted to mailing list. Is it ok?

Yury Sidorov,

I got your previous message with attachment too.

Vincent.

Not using sysutils means that you don't want exceptions. If you want to have run time errors converted into exceptions use sysutils. The patch has another probably undesired side effect: imaging someone installed an own errorproc to release resources (memory etc.) if he did so, he won't get that exception.

Yury Sidorov wrote

I found that try...except and try...finally do not work if SysUtils unit is not used (exception handling code is not called).

This behaviour is compatible with Delphi. It allows to exclude some procedures from being linked to the executable, when no exception handling is desired.

DoDi

Hello,

I had problems with my mailbox. Please resent your answer to this topic to my mailbox

Also, the previos patch was not complete. Here is complete and tested version.

Yury Sidorov,

From: "Florian Klaempfl"

I think try/finally/except should work without SysUtils. It works in Delphi. For example KOL library does not use SysUtils, but programmer can use try/finally/except to write crash-proof code.

In my final patch the described side effect with ErrorProc is solved. The exception will be raised after ErrorProc exit. Also stack dump on unhandled exception is fixed.

So I can not see any reason to do not include this patch...

Yury Sidorov,

Looks good.

So I can not see any reason to do not include this patch...

Applied, thx.

I think the idea is that exception handling should be kept separate in case a user wants to use his own exception handling. If the user explicitly wants to use exception handling, he just includes the sysutils unit.

However, I suppose if the sysutils unit involves some extra code bloat (due to initialization and finalization), and the user doesn't want to use sysutils in his project at all (but he does want exception handling) then there should be an option to use exception handling without the sysutils unit? (maybe a {$MODE HandleException} ?)

No.

Date sent: Thu, 07 Jul 2005 20:53:48 +0200
From: Florian Klaempfl
To: FPC developers' list
Subject: Re: [fpc-devel] Patch: Exception handling without SysUtils Send reply to: FPC developers' list

Isn't SysUtils used automatically in Delphi mode? That should be probably enough for Delphi compatibility, shouldn't it?

Tomas