Re: Changing soffice.bin to be console application on Windows

On 19.11.2018 18:48, Stephan Bergmann wrote:
> On 19/11/2018 16:38, Kaganski Mike wrote:
> > I have prepared a patch making soffice.bin a proper console Windows
> > application: https://gerrit.libreoffice.org/63572. The patch also
> > introduces a new launcher soffice.com (in addition to existing
> > soffice.exe). That is to make possible to call soffice from command
> > line, and have proper console launcher for that call.
>
> If there's both soffice.exe and soffice.com in the same directory 
> (assuming the "new launcher osffice.com" also goes into program\), what 
> will happen if some client starts just soffice w/o extension (either 
> from a shell, or from Windows' equivalent of exec, if it's possible to 
> call that w/o an extension)?  (program\soffice.exe is part of the stable 
> 3rd-party interface on Windows, but I'm not sure whether we officially 
> announce it as "program\soffice.exe is part of the stable interface" (so 
> client code could be considered broken if it calls that w/o extension) 
> or as "program\soffice is part of the stable interface".)

Yes, the soffice.com goes to the same program\ along with soffice.exe. 
And that's for the very purpose of the described scenario: when user 
calls soffice without an extension, .com is (usually) the preferred 
extension (subject to PATHEXT override), as described in [1]. Note that 
calling soffice without an extension is usually (always?) the case for 
console-like operation; while shell integration (including desktop 
shortcuts and registry) is done using explicit .exe. Also note that 
CreateProcess WinAPI only substitutes .exe in case the extension is 
omitted [2], so this scenario (calling soffice from a custom application 
without explicitly specifying .exe) should be unaffected.

The soffice.com is made to do exactly the same as soffice.exe (modulo 
being console application, and thus behave properly in different console 
and batch scenarios). In fact, the two are made as WinMain()|main() 
calling the real impl function which does everything that previously was 
in soffice.exe's WinMain.

Currently our help (and multiple resources everywhere) often (not sure 
if exclusively) mention commands like "soffice --switches". And both 
this and calling soffice.exe explicitly is currently inconsistent across 
platforms, because on other platforms, the call works as proper console 
call. So I see this as (hopefully) making the API consistent with what 
we announce.

[1] https://en.wikipedia.org/wiki/COM_file#Execution_preference
[2] 
https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessw