I actually didn’t – I did try it, but it didn’t work either and I hoped it wouldn’t be needed.
But I finally managed to make it work! As you say, I needed to compile the cheapglk in the same way (mingw32 CC and -DWIN32 option). The problem was that I got a warning for bzero function when compiling:
i686-w64-mingw32-gcc -g -Wall -DWIN32 -c -o cgdate.o cgdate.c
cgdate.c: In function ‘gli_date_to_tm’:
cgdate.c:45:5: warning: implicit declaration of function ‘bzero’ [-Wimplicit-function-declaration]
cgdate.c:45:5: warning: incompatible implicit declaration of built-in function ‘bzero’
But it did comopile. However, compiling glulxe then gave:
i686-w64-mingw32-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wno-unused -DWIN32 -o glulxe main.o files.o vm.o exec.o funcs.o operand.o string.o glkop.o heap.o serial.o search.o accel.o float.o gestalt.o osdepend.o profile.o unixstrt.o -L../cheapglk -lcheapglk -lm
../cheapglk/libcheapglk.a(cgdate.o): In function `gli_date_to_tm':
/media/win_d/documents/diplomka/linux/src/cheapglk/cgdate.c:45: undefined reference to `bzero'
collect2: error: ld returned 1 exit status
Makefile:48: recipe for target 'glulxe' failed
make: *** [glulxe] Error 1
However, if I comment out the line
it works like a charm and I can now run cheapglk+glulxe in Windows!
I’m not sure what I should do with the bzero function, though. Is it even needed, doesn’t the code set all its values anyway?
bzero isn’t a standard C function; it was originally added to some compilers to be more efficient than memset in the case of only writing zeroes.
However, I know that gcc and clang at least can optimize memset calls automatically, including checks for writing a block of zeroes. So that reason isn’t really applicable any more, and usually isn’t worth sacrificing portability.
If there’s only the one call, you can replace it with memset(tm, 0, sizeof(*tm)). If there are a lot of them, the Open Group spec recommends putting
#define bzero(b,len) (memset((b), '\0', (len)), (void) 0)
into your file to define bzero in terms of memset.
So…to jump in a bit late, I’m having trouble compiling cheapglk or getting close to it. And I want to, so I can have a way to use Zarf’s framework.
Myke, are you saying you build a binary that will allow people to stand STDIN to a text (non-windows) terminal and get game text back? If so, would you be willing to share it? It seems like you built it in a unix environment, and I just realized I’m pretty helpless without a CSPROJ or VCPROJ file or whatever.
They do work on my local binaries, which is kind of awesome. I think they are VERY worth loading to the IFArchive, because I think once people know they’re there, they will be able to go about more complex testing. Which helps everyone. It means testers won’t hit game-breaking bugs, and programmers won’t have to ask testers to retry stuff they already did. So I give a big YES to that.
Thank you very much for figuring how to build the bianries! It should be a huge help to me, and I’ll encourage others to use them, too.
Since you’ve figured out all the levers and screws for building on Windows, could I ask that you also do a build with RemGlk? It should go together the same as CheapGlk did.
(RemGlk output isn’t formatted for humans to read, but it includes all the stuff that CheapGlk throws away – styles, windows, ability to accept non-line-input events, etc. If you do serious testing, you may eventually want to switch to RemGlk.)
Which doesn’t look too bad, if we’re able to compile on Windows and poke around in Visual Studio Community or whatever. But it looks like there is some porting work to make things available for testing.
Sure, I’ll try doing that (not until next week, though) It might be worth noting that I can now build it for Windows (on Unix), not on Windows (which is something Andrew is struggling with and I, perhaps luckily, decided not to even go to the trouble of trying to make it work.
This looks troublesome – but to me it seems like a Python error (i.e. independent of the binary), or am I wrong? I know that a lot of stuff doesn’t work for Windows in Python but it does work on Unix, isn’t this the case too?
That was my initial guess, but the thing is–googling the specific error seemed to indicate a socket wasn’t getting open.
It may be easier, ultimately, to open up a Linux VM on my Windows machine and try things from there. That’s not something I’ve done, but it’s important enough for me to try. And if it works, that is more than good enough.
I don’t see why compiling for windows wouldn’t work, and so I suspected your solution was okay. But I wouldn’t be surprised if windows and unix handle sockets differently. WSAStartup is a Windows specific function, and as such, I suspect the problem is that the Unix code would need an Ifdef. There was no way to see this in advance.
Still, emulation seems like the simplest solution. Waiting for a 30mb download or whatever seems like it will take less time than figuring what is wrong and how to build on Windows, so I want to try that. Any solution that works is fine by me, and I’ve always needed the motivation to install Linux or a VM on my machine anyway. Something like this is well worth it.
Does the frotz that is built this way actually work, though?
Also, if anyone’s having trouble compiling glulxe (or simply too lazy :)), here are the compiled binaries for glulxe with cheapglk and remglk (cheapglulxe, remglulxe) for Linux: github.com/MikulasZelinka/glulx … ses/latest
Feel free to share them/post them anywhere (on ifarchive, for example).
Sure, it work, you can link it with Glk libs just like Glulxe. Son of Hunky Punk has been published and compiled frotz that same basic way. The Makefile for Android’s Linux (cross-compiler) is pretty similar: github.com/retrobits/son_of_hun … Android.mk