Hi Eliot,

On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Esteban,

On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

I���m slowly working on that VM because we want it to be the default for Pharo 8.��

In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour.��

To make this work, we need all platforms covered (and another huge quantity of changes here and there).��

Anyway, I didn���t merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didn���t feel pression to do it :)

How does that answer Norbert���s question?�� By doing the work in your own fork you risk forking.�� Do you want to fork?�� If not, why not do the work in opensmalltalk-vm?

This is old thing (there is a pull request now, since like 3 weeks).

I worked on my fork because that���s how you do it with git: you fork, you work, and you do a Pull Request when ready.��

I was explaining why the PR was not still done: I wanted to have covered the three platforms before doing it.��

I guess the terminology is confusing you?

Cheers!

Esteban

Cheers,��

Esteban

On 7 Aug 2018, at 08:50, Norbert Hartl <norbert@hartl.name> wrote:

What keeps you from doing a pull request to opensmalltalk-vm ?

Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm@gmail.com>:

Hi Ben,

Sorry for coming here so late, I didn���t see this thread before.��

I already have a working minheadless branch that was adapted to Eliot���s process.��

It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, that���s why is not pushed).

You can find this branch here:��

https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm

Interesting part is that I didn���t tackled any of the issues you are working on, so the work is easily mergeable :)��

Cheers,��

Esteban

Ps: with some changes in image, I���m using exclusively this VM since a couple of months and it works fine.

On 7 Aug 2018, at 07:22, Ben Coman <btc@openinworld.com> wrote:

On 7 August 2018 at 05:12, Eliot Miranda��<eliot.miranda@gmail.com>��wrote:

��

Hi Ben,��

Feel free to make this edit and commit

I'm pushing changes here...

https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-msvc2017

and the diff can be tracked here...

https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless...bencoman:MinimalisticHeadless-x64-msvc2017

------------------------

On 6 August 2018 at 13:22, Ben Coman <btc@openinworld.com> wrote:

On 6 August 2018 at 11:50, Ben Coman <btc@openinworld.com> wrote:

https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/windows/sqPlatformSpecific-Win32.c#L80
��typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int awareness);
�� �� C2059 sqPlatformSpecific-Win32.c:80 syntax error: '('
�� �� E0651 a calling convention may not be followed by a nested declarator.

The following change reduces build errors to 1...
�� typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness);

but I'm not sure of the implications.

I found the correct solution to this...

"The trick is placing the [call declaration] inside the parentheses"

https://stackoverflow.com/questions/4830355/function-pointer-and-calling-convention

i.e. the following compiles cleanly

typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int awareness);

-----------------------------

Now running the VM (without parameters) I get...

�� ��Debug Assertion Failed!

�� ��Program: ...\x64-Debug\dist\pharo.exe

�� ��File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c��

�� ��Line: 106

�� ��Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0

at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | _MCW_IC);

https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minheadless/windows/sqPlatformSpecific-Win32.c#L118

According to��https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx

x64 does not support��_MCW_PC or _MCW_IC

but I'm clueless about the implications of these FPU flags.

Could our math guys please advise?

Eliminating those two flags allows a VM run successfully without loading an Image.

i.e. it successfully passes...

�� ��osvm_initialize();

�� ��osvm_parseCommandLineArguments(argc, argv);

�� ��osvm_initializeVM();

Next is to try��loading an Image.

cheers -ben