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?


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: 


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...

and the diff can be tracked here...


------------------------
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"

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);


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