Hi Esteban, > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <esteba...@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 <norb...@hartl.name> wrote: >> >> What keeps you from doing a pull request to opensmalltalk-vm ? >> >>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <esteba...@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 <b...@openinworld.com> wrote: >>>> >>>>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.mira...@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 <b...@openinworld.com> wrote: >>>>> On 6 August 2018 at 11:50, Ben Coman <b...@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 >>> >
