Can anyone confirm if TProcessUTF8 handles unicode parameters under windows?

I'm using Win 8 64bit/Laz 32 bit trunk/FPC Trunk. I'm struggling here with no unicode background, reading madly and hunting away...

http://wiki.lazarus.freepascal.org/LCL_Unicode_Support makes it clear FPC is not unicode aware, though good improvements are being made in trunk...

I've traced through the code as best I can - TProcessUTF8 descends from TProcess. The overriden .Execute in TProcessUTF8, calls TProcess.Execute. Inside TProcess.Execute (win\process.inc) CreateProcess is called (which looks very much like it calls CreateProcessA, not CreateProcessW). And all the relevant parameters involved are PChars, whereas I think CreateProcessW will require PWideChars, confirming the CreateProcessA suspicion.

As I understand things, we'll need TProcess to be unicode aware before TProcessUTF8 itself is fully unicode aware....

My issue is down to a unicode filename being passed through as a parameter

Var
  FPlayerProcess: TProcessUTF8;
...
  FPlayerProcess.Executable:=FMPlayerPath;
  FPlayerProcess.Parameters.Add(AnsiToUTF8(Filename));

mplayer is reporting it can't find a corrupted version of the Filename I pass through. Works just fine with non-unicode filenames... (and I can pass mplayer the unicode filename in Command Prompt and it works there)

If someone could confirm my suspicions that TProcessUTF8 is likely the problem, I'll stop trying to fix the code at my end, and just put this down as a known issue for now (sure, and I'll log an item in the bugtracker though I can't see how to easily create a small test :) )... OTOH, if I'm completely wrong, I'll continue to slog away...

Many thanks

Mike T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140628/b07c6b5e/attachment-0001.html>

I answered in the forum.

Bart

I answered in the forum. Bart

Aye, thanks for that.

More information. I have now tried every combination of AnsiToUTF8(), UTF8ToAnsi(), SysToUTF8(), UTF8ToSys() and just simply FFilename in both TProcess and TProcessUTF8. All failed (and you can see my machine gun approach confirms my unicode ignorance).

I'm strongly leaning towards the possibility that this isn't going to work until win\process.inc itself is upgraded to be unicode aware (ie use CreateProcessW, upgrade CommandToList, and possibly other fixes). If I'm correct, this takes this issue away from being LazUtils related.

I'll do some tests on Linux this afternoon as I note that my problem might just be limited to Windows and I'll post a FPC bugtracker issue with a test case. I also note that this problem appears to be just limited to me, others report TProcessUTF8 working just fine for them (which makes a certain amount of sense, otherwise there would be related issues on the bugtracker)

Mike T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140629/70514b86/attachment.html>

Michael Thompson wrote

I'm strongly leaning towards the possibility that this isn't going to work until win\process.inc itself is upgraded to be unicode aware (ie use CreateProcessW, upgrade CommandToList, and possibly other fixes).

I would suspect this to be the case, yes.

Reinier Olislagers wrote

> I'm strongly leaning towards the possibility that this isn't going to > work until win\process.inc itself is upgraded to be unicode aware (ie > use CreateProcessW, upgrade CommandToList, and possibly other fixes). I would suspect this to be the case, yes.

At some point in time I have thougth about completely re-implementing TProcessUTF8 just for that reason but it would mean so much duplicate code (which is a nightmare for maintainers).
And all this would then become obsolete once fpc 2.8 comes around.... So, I gave up.

Bart

By 2am last night I was thinking similar thoughts. Had a quick bash at upgrading win\process.inc, reduced my fpc to a molten mess, also gave up :-)

And in your case I don't think giving up is the correct conclusion. Waiting patiently may be a better description :-)

I'm satisfied with the current state of affairs. That is, I understand it's not my code at fault and I'm happy to hear that plans for 2.8 include improved unicode awareness, so at this stage I'll just document this as an issue that users of the mplayer package need to be aware of. Also, if the fpc guys are working towards unicode awareness, I'll leave off the bugreport.

I may have a opportunity for extended coding later in the year, in which case I may investigate further. I find tinkering with the various internals fascinating. But for now, I'm running out of time...

Many thanks for everyone's time. Learning curves are always fun, but not for all parties...

Mike T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140629/53716430/attachment.html>