[Cuis-dev] Updates to VectorGraphics and VectorEnginePlugin

[Gerald Klix]

Thanks David for pointing this out.

Admittedly I don't know whether the VM uses the (highlevel (on Windows))
Posix functions or the kernel32.dll SetFilePointer function.
There is also this beaty (or beast):
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfilepointerex

It is my understanding that that the posix functions
are implement in terms of kern32.dll functions,
but AFIR it was around 1993 when I last did serious
Windows C programming.

I just started a build with asserts, maybe this gives me some
pointers into the right direction.


Best Regards,

Gerald



On 7/15/21 9:55 AM, stes--- via Cuis-dev wrote:
> 
> Based on experience with building 32bit and 64bit UNIX vm,
> See http://docs.openindiana.org/handbook/community/squeak/index.html
> using gcc and SunPro cc/c89, the error you post *COULD* be related to the behavior of fseek() and ftell()
> 
>         int fseek(FILE *stream, long offset, int whence);
> 
>         int fseeko(FILE *stream, off_t offset, int whence);
> 
> The difference being the off_t type and it is definition.
> 
> You could check on Windows the definition of off_t and how it is subject to -D flags.
> 
>  From lfcompile and lf64 (large file compile support on 32bit) on UNIX says :
> 
>         Applications  wishing  to  access  fseeko() and ftello() as well as the
>         POSIX and X/Open specification-conforming interfaces should define  the
>         macro  _LARGEFILE_SOURCE  to be 1 and set whichever feature test macros
>         are appropriate to obtain the desired environment (see standards(5)).
> 
> In the past, the Squeak configure script detected the lfcompile flags (or it still does),
> but unfortunately I think some files do not #include "config.h", and then they don't have the right -D flags,
> we have to make sure largefile support is enabled in the 32bit case on UNIX at least
> (apparently, I'm not sure why this is the case).
> 
> Basically this comes down to using c89 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> 
>         The  following example compiles a program with a "large" off_t and uses
>         fseeko(), ftello(), and yacc(1).
> 
>           $ c89 -D_LARGEFILE_SOURCE                \
>                 -D_FILE_OFFSET_BITS=64 -o foo      \
> 
> 
> So what could be happening in the Windows 32bit case, is that the necessary defines are missing.
> 
> It's possible.
> 
> A few months ago, I could build a 32bit VM with "autoconf" configure would use/find the correct settings in config.h.
> 
> But this stopped working a while ago, when some header/include files were moved/cleaned up.
> 
> It is very easy to break unintentionally one platform while fixing the header/include files for another platform, unfortunately ... !
> 
> David Stes
> 
> ----- Op 15 jul 2021 om 9:31 schreef cuis-dev cuis-dev at lists.cuis.st:
> 
>> I tried the latest Cog revision.
>> 64-bit works, 32-bit gives the following error
>> message when reading the an image:
>> "Image file read problem (0 out of 4 bytes read).
>>
>> I also tried Marcel Taumel's action branch to no avail.
>>
>> So still no 32bit windows vm.
>>
>>
>> Best Regards,
>>
>> Gerald
>>
>>
>>
>> On 7/15/21 8:28 AM, Gerald Klix via Cuis-dev wrote:
>>> Hi Juan,
>>>
>>> On 7/14/21 8:21 PM, Juan Vuletich via Cuis-dev wrote:
>>>> Hi Gerald,
>>>>
>>>> On 7/7/2021 5:26 PM, Gerald Klix via Cuis-dev wrote:
>>>>> Juan,
>>>>>
>>>>> do you need a 32-bit Windows build?
>>>>> I am considering to do this anayways, because build
>>>>> for my favorite 32-bit platform -- RasPi -- are broken.
>>>>> Just tell me if you need it by tomorrow.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Gerald
>>>>
>>>> A 32 bit Windows build would be really useful to me.
>>>>
>>>> Thanks,
>>>>
>>> In a nutshell: "No working 32-bit-Windows build".
>>>
>>>
>>> The details:
>>>
>>> I thought that you would like to have a 32-bit VM
>>> and started to build a 32-bit VM on Windows a week ago.
>>> Wonders over wonders, after installing the appropriate 32bit-clang
>>> compiler and setting the "right" environment variable
>>> (COMPILER_TO_USE), the build succeeded.
>>> The resulting VM was not able to read the image, it complained
>>> about not being able to read bytes 0 (maybe 1) to 4.
>>> I decided to dowmload the community version of Visual Studio 2019
>>> and give it shot. Alas, here I got compilation errors
>>> for the first file.
>>> A (disturbing) side-note: If you use gcc for windows
>>> 32-bit builds it looks like the build system uses
>>> the 64-bit compiler, which complains about
>>> bad printf-format strings (using "%d" to print
>>> a pointer cast to an integer). Needless to say,
>>> that this VM does not even reach the point
>>> where it can complain about not being
>>> able to read the image ...
>>>
>>> I refrained from posting these results on the mailing-list,
>>> it would have been another rant of mine about
>>> "cargo-cult programming".
>>>
>>> While I am writing this I tried again to build
>>> a 32-bit VM with the latest
>>> Cog revision, without any patches an of course no plugin.
>>> Let's see were this will lead to.
>>>
>>>
>>> Best Regards,
>>>
>>> Gerald
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev