VOGONS


Compiling IBMulator for Windows...

Topic actions

First post, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie

While IBMulator 0.8 is restricted to the 80286-based IBM PS/1 Model 2011, the latest source code on the other hand recently added support for the 80386-based IBM PS/1 Model 2121. For this reason entirely, I'm trying to compile IBMulator for Windows, however, I have found a serious problem here.

The problem here is that the program specifically requires a special version of libRocket (downloaded from the IBMulator repository), following all of the instructions in the files that the author provided. However, the compile process for libRocket fails completely with the following errors:

C:\MinGW\libRocket\Build>mingw32-make
Scanning dependencies of target RocketCore
[ 1%] Building CXX object CMakeFiles/RocketCore.dir/C_/MinGW/libRocket/Source/Core/BaseXMLParser.cpp.obj
In file included from c:\mingw\librocket\include\rocket\core\core.h:31:0,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\Types.h:84:9: error: 'uintptr_t' does not name a type
typedef uintptr_t FileHandle;
^
c:\mingw\librocket\include\rocket\core\Types.h:85:9: error: 'uintptr_t' does not name a type
typedef uintptr_t TextureHandle;
^
c:\mingw\librocket\include\rocket\core\Types.h:86:9: error: 'uintptr_t' does not name a type
typedef uintptr_t CompiledGeometryHandle;
^
c:\mingw\librocket\include\rocket\core\Types.h:87:9: error: 'uintptr_t' does not name a type
typedef uintptr_t DecoratorDataHandle;
^
In file included from c:\mingw\librocket\include\rocket\core\Decorator.h:34:0,
from c:\mingw\librocket\include\rocket\core\core.h:37,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\Texture.h:67:2: error: 'TextureHandle' does not name a type
TextureHandle GetHandle(RenderInterface* render_interface) const;
^
In file included from c:\mingw\librocket\include\rocket\core\core.h:37:0,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\Decorator.h:62:10: error: 'DecoratorDataHandle' does not name a type
virtual DecoratorDataHandle GenerateElementData(Element* element) = 0;
^
c:\mingw\librocket\include\rocket\core\Decorator.h:65:34: error: 'DecoratorDataHandle' has not been declared
virtual void ReleaseElementData(DecoratorDataHandle element_data) = 0;
^
c:\mingw\librocket\include\rocket\core\Decorator.h:86:47: error: 'DecoratorDataHandle' has not been declared
virtual void RenderElement(Element* element, DecoratorDataHandle element_data) = 0;
^
c:\mingw\librocket\include\rocket\core\Decorator.h:89:15: error: 'DecoratorDataHandle' does not name a type
static const DecoratorDataHandle INVALID_DECORATORDATAHANDLE = 0;
^
In file included from c:\mingw\librocket\include\rocket\core\PropertySpecification.h:32:0,
from c:\mingw\librocket\include\rocket\core\DecoratorInstancer.h:34,
from c:\mingw\librocket\include\rocket\core\core.h:38,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\Element.h:342:107: error: 'DecoratorDataHandle' has not been declared
bool IterateDecorators(int& index, PseudoClassList& pseudo_classes, String& name, Decorator*& decorator, DecoratorDataHandle& decorator_data);
^
In file included from c:\mingw\librocket\include\rocket\core\core.h:52:0,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\FileInterface.h:57:10: error: 'FileHandle' does not name a type
virtual FileHandle Open(const String& path) = 0;
^
c:\mingw\librocket\include\rocket\core\FileInterface.h:60:21: error: 'FileHandle' has not been declared
virtual void Close(FileHandle file) = 0;
^
c:\mingw\librocket\include\rocket\core\FileInterface.h:67:49: error: 'FileHandle' has not been declared
virtual size_t Read(void* buffer, size_t size, FileHandle file) = 0;
^
Show last 53 lines
In file included from c:\mingw\librocket\include\rocket\core\core.h:52:0,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\FileInterface.h:73:20: error: 'FileHandle' has not been declared
virtual bool Seek(FileHandle file, long offset, int origin) = 0;
^
c:\mingw\librocket\include\rocket\core\FileInterface.h:77:22: error: 'FileHandle' has not been declared
virtual size_t Tell(FileHandle file) = 0;
^
c:\mingw\librocket\include\rocket\core\FileInterface.h:83:24: error: 'FileHandle' has not been declared
virtual size_t Length(FileHandle file);
^
In file included from c:\mingw\librocket\include\rocket\core\core.h:57:0,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\Geometry.h:91:2: error: 'CompiledGeometryHandle' does not name a type
CompiledGeometryHandle compiled_geometry;
^
In file included from c:\mingw\librocket\include\rocket\core\core.h:67:0,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\RenderInterface.h:62:97: error: 'TextureHandle' has not been declared
virtual void RenderGeometry(Vertex* vertices, int num_vertices, int* indices, int num_indices, TextureHandle texture, const Vector2f& translation) = 0;
^
In file included from c:\mingw\librocket\include\rocket\core\core.h:67:0,
from C:\MinGW\libRocket\Source\Core\precompiled.h:31,
from C:\MinGW\libRocket\Source\Core\BaseXMLParser.cpp:28:
c:\mingw\librocket\include\rocket\core\RenderInterface.h:73:10: error: 'CompiledGeometryHandle' does not name a type
virtual CompiledGeometryHandle CompileGeometry(Vertex* vertices, int num_vertices, int* indices, int num_indices, TextureHandle texture);
^
c:\mingw\librocket\include\rocket\core\RenderInterface.h:77:38: error: 'CompiledGeometryHandle' has not been declared
virtual void RenderCompiledGeometry(CompiledGeometryHandle geometry, const Vector2f& translation);
^
c:\mingw\librocket\include\rocket\core\RenderInterface.h:80:39: error: 'CompiledGeometryHandle' has not been declared
virtual void ReleaseCompiledGeometry(CompiledGeometryHandle geometry);
^
c:\mingw\librocket\include\rocket\core\RenderInterface.h:97:27: error: 'TextureHandle' has not been declared
virtual bool LoadTexture(TextureHandle& texture_handle, Vector2i& texture_dimensions, const String& source);
^
c:\mingw\librocket\include\rocket\core\RenderInterface.h:103:31: error: 'TextureHandle' has not been declared
virtual bool GenerateTexture(TextureHandle& texture_handle, const byte* source, const Vector2i& source_dimensions);
^
c:\mingw\librocket\include\rocket\core\RenderInterface.h:106:30: error: 'TextureHandle' has not been declared
virtual void ReleaseTexture(TextureHandle texture);
^
CMakeFiles\RocketCore.dir\build.make:57: recipe for target 'CMakeFiles/RocketCore.dir/C_/MinGW/libRocket/Source/Core/BaseXMLParser.cpp.obj' failed
mingw32-make[2]: *** [CMakeFiles/RocketCore.dir/C_/MinGW/libRocket/Source/Core/BaseXMLParser.cpp.obj] Error 1
CMakeFiles\Makefile2:97: recipe for target 'CMakeFiles/RocketCore.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/RocketCore.dir/all] Error 2
Makefile:115: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

C:\MinGW\libRocket\Build>

The reason for why I'm trying to compile this on Windows is that not only am I looking for a way to easily build the source on Windows itself (since that's what I'm compiling it for), but also because of the fact that running Linux inside of a virtual machine is far more resource-intensive than just running the MinGW environment, meaning that the latter would only be used as a last resort. I followed the instructions on the project's page, but they appear to be incorrect since libRocket did NOT compile correctly as seen above.

I already have experience with building emulators since I already develop and compile my own emulator (based off of PCE) daily, though its support for the IBM PS/2 series and the Intel 80386 CPU are both still in their early stages, and even 86box's IBM PS/1 Model 2121 emulation still has lot's of problems, which is why I'm trying to compile the latest IBMulator source code so that I can use that until my own emulator's 80386 CPU support is more complete.

Reply 2 of 22, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie
ripa wrote:

I guess MinGW is not compiling in C++11 mode.

Is there an easy way to turn on this behavior though? As in, are there any instructions that I could follow that you could post or link to here?

Also, following the response that I received elsewhere when asking the same question, I tried including the "include" directory in the path and even copying it over the one in the source folder, and neither worked at all. I also have strong suspicions that the instructions that were posted for building this special version of libRocket on MinGW were incorrect, or that the user uploading it didn't check to make sure that it actually builds correctly under MinGW on Windows first before making it available. The author of the IBMulator program is mainly a Linux user (and even said so himself in various posts), so that unfortunately can't be ruled out.

Still, I am open to being incorrect about this (which I hope that I am), which is why I'm asking now whether there are any proper instructions for turning on "C++11" compile mode so that I can either correct the problem there (if this corrects the problems with the build process) or at least rule that out as being the cause if it still has problems compiling.

Reply 3 of 22, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

If you cannot make MingW support C++11 then you can probably just do small changes to the source code to allow compilation. It seems most (all?) errors stem from not understanding uintptr_t type.

typedef uintptr_t CompiledGeometryHandle;

So you have few options

1) Try to include <stdint.h>
2) add a #define uintptr_t uint64_t
3) add a #define uintptr_t size_t

See if any of those work.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 4 of 22, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie
vladstamate wrote:
If you cannot make MingW support C++11 then you can probably just do small changes to the source code to allow compilation. It s […]
Show full quote

If you cannot make MingW support C++11 then you can probably just do small changes to the source code to allow compilation. It seems most (all?) errors stem from not understanding uintptr_t type.

typedef uintptr_t CompiledGeometryHandle;

So you have few options

1) Try to include <stdint.h>
2) add a #define uintptr_t uint64_t
3) add a #define uintptr_t size_t

See if any of those work.

I specifically need to force it to support C++11 in this case to rule that out as being the cause. What I'm trying is to compile the unmodified source code using the MinGW environment itself. And if there are already issues with compiling the libRocket source code then it's also likely that the same is true for IBMulator itself.

Anyway, I'll try to see if there are any instructions online about it. Obviously I would also try contacting the author himself if he could even be reached, but since he appears not to be online that much at all, I doubt that I would receive anything back from him in return (assuming that he even checks his messages at all), which is why I asked here instead.

Reply 5 of 22, by ripa

User metadata
Rank Oldbie
Rank
Oldbie

C++11 support depends on the compiler that comes with MinGW: GCC. Check which version of MinGW / GCC you have. E.g., on the command line, g++ --version, if I remember correctly. The manual here explains everything: https://gcc.gnu.org/onlinedocs/

To enable C++11 support in GCC, you need to use command line switch -std=c++11 or the older -std=c++0x when invoking the compiler. The compiler is invoked by the build system used by libRocket. When building, you can probably make it print out the compiler commands as they are executed with some "verbose" switch. You can then see if the c++11 switch is being used or not. If not, you need to study libRocket's build system to find out how to enable it.

Reply 6 of 22, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie
ripa wrote:

C++11 support depends on the compiler that comes with MinGW: GCC. Check which version of MinGW / GCC you have. E.g., on the command line, g++ --version, if I remember correctly. The manual here explains everything: https://gcc.gnu.org/onlinedocs/

To enable C++11 support in GCC, you need to use command line switch -std=c++11 or the older -std=c++0x when invoking the compiler. The compiler is invoked by the build system used by libRocket. When building, you can probably make it print out the compiler commands as they are executed with some "verbose" switch. You can then see if the c++11 switch is being used or not. If not, you need to study libRocket's build system to find out how to enable it.

Would typing "mingw32-make -std=c++11" at the command prompt work (as opposed to "mingw32-make" by itself as the build instructions said)?

Reply 7 of 22, by ripa

User metadata
Rank Oldbie
Rank
Oldbie

No. "mingw32-make" is not the compiler. You need to figure out how to pass parameters to the compiler in the build system (looks like CMake in this case). This might be relevant: http://stackoverflow.com/questions/11783932/h … g-in-cmake-file

Reply 8 of 22, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie
ripa wrote:

No. "mingw32-make" is not the compiler. You need to figure out how to pass parameters to the compiler in the build system (looks like CMake in this case). This might be relevant: http://stackoverflow.com/questions/11783932/h … g-in-cmake-file

I see the instructions now, but I don't completely understand them. Are the flags added when running CMAKE from the command shell, or would this require making changes to the makefile?

Reply 10 of 22, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

No it is not. But you have to be willing to do something about it other than just wait for it to magically work perfectly. If you are not willing to tinker with it you will not get far. Open source software is often like that. You are unfortunately waiting for someone to give you the magic command line which won't happen.

Like I gave advice before few posts before you might need to dive in, make some changes.

Yes, this will require either changing the makefile file or the source code itself.

Just try different things.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 12 of 22, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

For that you can try add "VERBOSE=1" or "-n" to your make command or export "CMAKE_VERBOSE_MAKEFILE=ON".

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 13 of 22, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie
vladstamate wrote:
No it is not. But you have to be willing to do something about it other than just wait for it to magically work perfectly. If yo […]
Show full quote

No it is not. But you have to be willing to do something about it other than just wait for it to magically work perfectly. If you are not willing to tinker with it you will not get far. Open source software is often like that. You are unfortunately waiting for someone to give you the magic command line which won't happen.

Like I gave advice before few posts before you might need to dive in, make some changes.

Yes, this will require either changing the makefile file or the source code itself.

Just try different things.

The problem here is that the users in this thread never provided any evidence at all to suggest that this would correct any of the issues that I have with compiling it, since from what I can tell it's quite clear that they did not try this for themselves. If anyone here had actually tried compiling it in Windows using the instructions that the author provided, then they would actually know what was going on and as such would be in a far better position to provide assistance in this topic.

Switching between different versions of the source code is also problematic (not to mention extremely inconvenient to say the least) which is why I'm only going to follow whatever instructions are by far the most likely to correct any of the problems here. If there is no evidence at all to suggest that the users replying did not actually try this for themselves, then I'm extremely doubtful that their suggestions would even have any effect at all.

And as I said beforehand, I would definitely have contacted the author of the program itself for assistance in this case, but since the author does not even appear to be active at all, then I simply assumed that I wouldn't get a reply from him.
================================================================================================================================
What I really need, most of all, is for at least one person here to actually TRY compiling it in Windows for themselves, so that they would at least be able to try to see what's going on and to try to correct any issues from there. Only then would they actually know if there is a way to correct this issue. I would also try the same thing myself except that I'm already quite busy with other software-related projects as it is, and even then that's only when I'm at my PC.
================================================================================================================================
EDIT: The problem here is not with the main IBMulator program (although that might also be experiencing compile errors under MinGW) but rather with the special version of libRocket that it requires. What I really need is for someone to at least be able to compile the special version of libRocket (which is available from the author's page).

Reply 15 of 22, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie
ripa wrote:

Then all I can say is good luck!

Then what's the point of responding? If it's quite clear that you haven't tried this yourself, then naturally most people would simply assume that it would either make the problem worse or (at best) have no effect at all. You said that you had some possible solutions, therefore it is entirely up to you to prove that they would work. It is not up to everyone else to prove the negative; it is up to you yourself to prove the positive.

And some of us don't have time to go through trying each and every possible and conceivable feature modification for ourselves, because many of us simply don't have the time to do all of that. Many people here have jobs, or are working on their own software projects, or are working on other types of projects in general.

Anyway, I'm going to try some of these suggestions anyway, once I have the time, but it's doubtful that any of them would work at all if there was no evidence to support any of these claims.

Reply 16 of 22, by valnar

User metadata
Rank Oldbie
Rank
Oldbie

My first PC ever was a PS/1 model 2121 386SX/16. I have fond memories of that four quadrant start screen with archaic DOS 4.0 and Windows 3.0

Alas my main rig is Windows 7 32-bit for reasons of backward compatibility so IBMulator doesn't run on my main rig being 64-bit, although I have seen it in action. I can get PS1 2121 emulation through PCEM, but it's not quite the same.

If you do manage to recompile IBMulator, I'd implore you to make it 32-bit as well. 😀

Thanks.

Reply 17 of 22, by Battler

User metadata
Rank Member
Rank
Member

- SoftPCMuseum_: It takes literally a few minutes to do the few changes to the makefiles and the code you were suggested to do, and compile. And you clearly have time to post complaints this long on a forum, so how do you not have time to do the change?
While I agree with you on some things, I really think you should stop expecting people to serve you things on a silver platter...

Reply 18 of 22, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie
Battler wrote:

- SoftPCMuseum_: It takes literally a few minutes to do the few changes to the makefiles and the code you were suggested to do, and compile. And you clearly have time to post complaints this long on a forum, so how do you not have time to do the change?
While I agree with you on some things, I really think you should stop expecting people to serve you things on a silver platter...

I did not mean for this to sound like I was expecting people to serve me things on a silver platter, since that was not my intention at all. All that I was asking for was evidence to suggest that this would actually work (or to prove that they had actually tried this for themselves) because otherwise it would have been a complete waste of my time if that was not the case. Infact, I actually tried spending considerable amounts of time working on setting up the development environment, time that had already taken me away from my own emulator's development as it is, since it involved not only setting up the MinGW environment and terminal, but also configuring each series of tools required by the development environment so that it was exactly what the author stated was required, with all of this in the end becoming an extremely complicated process in itself. If I had been expecting everyone to serve me everything on a silver platter then I clearly wouldn't have gone into this much effort in setting up such a completely new environment (and even sacrificing some time that would normally be used for developing my own emulator in the process).

Remember that this was also done at my expense at that (as stated quite clearly above), so if I am not able to continue from there, then there is a very good reason for why that is the case. Remember that a similar case would occur for someone writing BASIC programs if they were to switch over from writing for AppleSoft BASIC to GWBASIC or Microsoft QuickBasic - they would also have to devote major amounts of time in setting up a completely new development environment, not to mention relearning much of the BASIC language since there are major differences between the two. They would also need help in switching over to the new "dialect" of BASIC at that.

Reply 19 of 22, by SoftPCMuseum_

User metadata
Rank Newbie
Rank
Newbie
ripa wrote:

C++11 support depends on the compiler that comes with MinGW: GCC. Check which version of MinGW / GCC you have. E.g., on the command line, g++ --version, if I remember correctly. The manual here explains everything: https://gcc.gnu.org/onlinedocs/

To enable C++11 support in GCC, you need to use command line switch -std=c++11 or the older -std=c++0x when invoking the compiler. The compiler is invoked by the build system used by libRocket. When building, you can probably make it print out the compiler commands as they are executed with some "verbose" switch. You can then see if the c++11 switch is being used or not. If not, you need to study libRocket's build system to find out how to enable it.

Normally double-posting might not be allowed here, but do you know where the switch is supposed to be added in the Makefile? I currently have it open on my PC, but I have no idea as to where the flags are supposed to be placed, especially given how large it is (for a text file, that is). When invoking the compiler again, I see now that the file itself is created automatically when running the "mingw32-make" command.

EDIT: Apparently, I had the wrong file. The correct file was CMakeLists.txt. Still, I am not at all sure as to where the commands are supposed to be placed, especially since there are separate listings for different platforms.

EDIT 2: There is also another file called CMakeCache.txt, which also uses compile flags. Still, I am not sure as to where these specific flags should be placed.