In our previous episode, Sven Barth said:
> > argv and argc is not really raw data, and on many platforms (like
> windows) processed.
> >
> > If you want to use the raw data, you'll need OS specific functions
> > (getcommandlinew for e.g. Windows), or, in case of the Unix RTL, the
> > operatingsys
Am 13.04.2016 09:04 schrieb "Marco van de Voort" :
>
> In our previous episode, Martin Schreiber said:
> > > Anyway, I never liked the fact that argv and argc are exported
symbols. If
> > > they weren't public, we could change them at will and/or have
differing
> > > implementations and encodings d
In our previous episode, Martin Schreiber said:
> > Anyway, I never liked the fact that argv and argc are exported symbols. If
> > they weren't public, we could change them at will and/or have differing
> > implementations and encodings depending on target. I would deprecate them
> > (being public
On Tuesday 12 April 2016 18:46:15 Marco van de Voort wrote:
>
> Anyway, I never liked the fact that argv and argc are exported symbols. If
> they weren't public, we could change them at will and/or have differing
> implementations and encodings depending on target. I would deprecate them
> (being
Am 12.04.2016 18:46 schrieb "Marco van de Voort" :
>
> In our previous episode, Michael Van Canneyt said:
> > >> If argv/argc is known to be UTF8 encoded, then I see no problem with
> > >> keeping getopts ?
> > >
> > > Getopts is not utf8 but shortstring, so ACS on Windows. Or do you
plan to
> > >
In our previous episode, Michael Van Canneyt said:
> >> If argv/argc is known to be UTF8 encoded, then I see no problem with
> >> keeping getopts ?
> >
> > Getopts is not utf8 but shortstring, so ACS on Windows. Or do you plan to
> > redo it using utf8string or unicodestring?
>
> I don't necessari
On Tue, 12 Apr 2016, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
I guess the only way, as always, is to have two duplicate systems on
windows. One wide that is for unicode, (unicodestring paramstr and
D2009 compatible tapplication), one for old legacy ansi ap
In our previous episode, Michael Van Canneyt said:
> > I guess the only way, as always, is to have two duplicate systems on
> > windows. One wide that is for unicode, (unicodestring paramstr and
> > D2009 compatible tapplication), one for old legacy ansi apps. (getopts etc).
> If argv/argc is kn
On Tue, 12 Apr 2016, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
They are not supported, because we get the original command line data
using the ansi version of the API call (see setup_arguments() in
rtl/win/syswin.inc). If this is "fixed", then we also have to decide
In our previous episode, Jonas Maebe said:
> They are not supported, because we get the original command line data
> using the ansi version of the API call (see setup_arguments() in
> rtl/win/syswin.inc). If this is "fixed", then we also have to decide
> what to do with the argv p(ansi)char (a g
On Mon, 11 Apr 2016 19:31:23 +0200
Mattias Gaertner wrote:
> Hi,
>
> Are there any plans to extend FPC to support Unicode file paths under
> Windows?
To clarify: I mean the compiler fpc.exe.
> Of course this also means the other tools, like fpcres, fpmake and
> fppkg.
> Would this require a ne
On Mon, 11 Apr 2016 22:45:54 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:
>[...]
> Well, afaik on Windows unicode commandlines are supported in $mode
> delphiuncode. Overloaded unicode(string) versions of paramstr handle it
> (unit uuchar)
>
>
> > And when executing the compiler dire
Marco van de Voort wrote:
Well, afaik on Windows unicode commandlines are supported in $mode
delphiuncode.
They are not supported, because we get the original command line data
using the ansi version of the API call (see setup_arguments() in
rtl/win/syswin.inc). If this is "fixed", then we al
In our previous episode, Mattias Gaertner said:
> > > Of course this also means the other tools, like fpcres, fpmake and
> > > fppkg.
> > > Would this require a new flag?
> >
> > Yes. cmd.exe with /u ? :-)
>
> Is this already supported?
Well, afaik on Windows unicode commandlines are supported i
On Mon, 11 Apr 2016 21:05:55 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:
> In our previous episode, Mattias Gaertner said:
> > Are there any plans to extend FPC to support Unicode file paths under
> > Windows?
> > Of course this also means the other tools, like fpcres, fpmake and
> >
In our previous episode, Mattias Gaertner said:
> Are there any plans to extend FPC to support Unicode file paths under
> Windows?
> Of course this also means the other tools, like fpcres, fpmake and
> fppkg.
> Would this require a new flag?
Yes. cmd.exe with /u ? :-)
_
On Mon, 11 Apr 2016, Mattias Gaertner wrote:
Hi,
Are there any plans to extend FPC to support Unicode file paths under
Windows?
Of course this also means the other tools, like fpcres, fpmake and
fppkg.
Would this require a new flag?
The rtl already support this. But none of the tools curren
On Mon, 11 Apr 2016 20:02:32 +0200
Sven Barth wrote:
> Am 11.04.2016 19:31 schrieb "Mattias Gaertner" :
>[..]
> In the end the Windows RTL should only use the *W functions and thus fully
> allow for Unicode paths. Or what do you mean? (especially with your last
> question?)
What about printing t
Am 11.04.2016 19:31 schrieb "Mattias Gaertner" :
>
> Hi,
>
> Are there any plans to extend FPC to support Unicode file paths under
> Windows?
> Of course this also means the other tools, like fpcres, fpmake and
> fppkg.
> Would this require a new flag?
>
In the end the Windows RTL should only use
Hi,
Are there any plans to extend FPC to support Unicode file paths under
Windows?
Of course this also means the other tools, like fpcres, fpmake and
fppkg.
Would this require a new flag?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
20 matches
Mail list logo
