Uncertain future for openMSX's Windows version

Source: openMSX website

In the past few years, openMSX has become available for various platforms, after it initially started as a Linux application. Unfortunately, support for the Windows platform has become an uncertainty recently. While the openMSX team is fairly large, there's currently no-one in their team to build and test a Windows version of openMSX on a structural base. As the team intended to release version 0.6.3 of their emulator shortly, there is now a reasonable chance that this new release will come without a version for Windows. Considering some of the new functionality and fixes that have been added recently, this would of course be a great pity for the Windows part of the MSX community.

Hoping to avoid this situation, the openMSX team has once more placed a request for help on their website. Programmers who care to invest some of their time into the building and testing the Windows version of this emulator on a structural basis are invited to contact the team as soon as possible.

Relevant link: openMSX website

Comments (36)

By Prodatron

Paragon (1843)

28-08-2007, 00:44

Bad news As I wanted to investigate the GFX9000 soon, I guess OpenMSX will become a very important emulator in the future for me.
Unfortunately I am not experienced in Windows programming, so I can't help here at the moment...

By Vampier

Prophet (2413)

28-08-2007, 07:53

Ow Really? The horror

Vampier@VAMPIER-LAPTOP /home/trunk
$ make
Setting up files for openMSX
make[1]: Entering directory `/home/openMSX'
Build configuration:
  Platform: x86-mingw32
  Flavour:  i686
  Profile:  false
  Subset:   full build
Installing openMSX:
  Executable...
  Data files...
  Documentation...
  C-BIOS...
Installation complete... have fun!
make[1]: Leaving directory `/home/openMSX'
Creating installer: openmsx-0.6.3-rc1-win32-bin.exe

Only one problem, I can't compile the 'new' Catapult.

By NYYRIKKI

Enlighted (6067)

28-08-2007, 08:48

Does this mean, that you don't even need Windows to compile windows version? That sounds funny. It makes real cross developing possible also in PC-computers.

By Manuel

Ascended (19469)

28-08-2007, 08:55

For now you still need Windows to compile it (but with MinGW and MSYS, which looks UNIXy). We are going to look for cross compilation but that doesn't solve the problem at all: still no structural Windows support.

Vampier: the new Catapult isn't ready for release yet anyway (and it does not need compilation). But it will be quite cool, though

By tfh

Prophet (3347)

28-08-2007, 09:38

Looking at Vampiers post: Does this mean there will be a Win32 release?

By Manuel

Ascended (19469)

28-08-2007, 10:40

Prodatron: for most maintenance you don't need to be a very experienced programmer (although it would certainly help to solve the (rare) specific Win32 issues). It does help to compile openMSX a couple of times a week (so, you need to follow the latest developments) and be in the IRC channel a couple of times a week. Reporting bugs (quickly and often) helps a lot as well.

TFH: as I stated on our website: possibly, but that doesn't solve the long term problem at all. We need structural Windows support, not incidental as it would make the Windows port crappier and crappier, because of all kinds of problems that creep in and get unnoticed. This is already happening now.

By hap

Paragon (2042)

28-08-2007, 11:17

I volunteered, but I guess I don't have enough openMSXtime
Wouldn't it be feasible for one of the openMSX developers to dual-boot?

By wolf_

Ambassador_ (10109)

28-08-2007, 11:23

Wouldn't it be feasible for one of the openMSX developers to dual-boot?

Don't bother trying to convince 'em.. Been there, done that.

By Manuel

Ascended (19469)

28-08-2007, 11:35

hap: your work is still much appreciated! Don't get me wrong here. But I was under the impression that you were only helping temporarily as well. If you want to help with the actual maintenance, that would be great Maybe after the current hectics are over, there is less time needed and you could at least compile and test a bit regularly?

Dual booting is not an option: the current devs don't have licenses (Windows/vmware) and do not like the windows environment enough to actually boot it and leave the good old system they're used to (not regularly enough at least). openMSX is our hobby and it would be no fun to start using an environment we don't like (and hobbies should be fun of course!). We really need a devoted person for a structural solution.

By hap

Paragon (2042)

28-08-2007, 13:10

Maybe after the current hectics are over, there is less time needed and you could at least compile and test a bit regularly?
We'll see

I currently don't have a valid Windows license either (shh, don't tell anyone). Disliking an OS shouldn't prevent you from booting it once or twice a week just for the purpose of compiling openMSX on it.

By yakumo

Expert (75)

28-08-2007, 13:41

manuel, what about WINE for linux? Have you already tried it?

By Huey

Prophet (2694)

28-08-2007, 14:00

If there won't be a regular Win release other emu's will fill in the gap. I can live with that.

By wolf_

Ambassador_ (10109)

28-08-2007, 14:12

Still, the major emulators around are all quite different. Not everyone could just jump to another emulator. When it comes to testing/bughunting Edwin_ and me always make sure we run the exact same configuration, to rule out emulator/configuration errors, and since he's on Linux, the presence of openMSX for Windows would be somewhat of an importance for me..

Next to that, currently some very nice sound-related things have been added which are currently unique to openMSX afaik.

By Manuel

Ascended (19469)

28-08-2007, 14:38

hap: I hope you keep visiting our channel, it will definately help.
Booting once or twice a week to build: it's just not going to happen, a more structural solution is needed (I keep saying it, but it's true). It should be 'natural' to do this.

yakumo: Wine isn't suitable for this (crosscompilation would be better), but it also lacks the long term solution.

What I want to say here: we might probably get it compiled for this release somehow (no promises, though), but there's a need for a structural solution to prevent Win32 bitrot and (much) delayed releases for Win32.

By yakumo

Expert (75)

28-08-2007, 19:10

@manuel:

Precisely. What I am saying is crosscompile using linux and test using WINE in linux. Remember that Wine Is Not an Emulator, its a port of the Windows API, and although still in beta stage, it is very mature.

You should take a look.

By Edwin

Paragon (1182)

28-08-2007, 19:50

Last time I tried openmsx-win32 with wine it wouldn't run at all. Wine has matured a lot, but when you move away from the most popular applications, you'll see that it still has a long way to go.

By snout

Ascended (15187)

29-08-2007, 15:52

It would be a shame if one of the most accurate and actively developed MSX emulators would not become available in a Windows-flavor anymore.

Haven't the requirements for becoming a win32-compiler become a bit too high? Compiling once or twice a week like hap offered already sounds quite active to me. Last time I checked openMSX was a hobbyist open source project, right? There's only a certain amount of time anyone can put into it and... at least it's better than absolutely nothing.

What happened to the previous win32-openMSX-staff anyways?

By Samor

Prophet (2174)

29-08-2007, 19:14

no Windows version would be a shame. I can't develop it, but testing is something I can do, at least. It's just hard to tell how much time I'd have for it.

By Edwin

Paragon (1182)

29-08-2007, 19:18

It's not just the compiling and testing. When something doesn't work right that appears to be specific to windows, it needs to be debugged. This can be rather time consuming and sometimes difficult. Without this, weird issues will start creeping in.

By Prodatron

Paragon (1843)

30-08-2007, 01:29

I am wondering, what is the general issue: Do you still add platform-specific stuff to OpenMSX, or is cross-compiling even of non-platform-specific code a gamble? Sorry, this might sound very stupid, as I don't have much experience in direct Linux/Windows coding. But that would be quite interesting to know for me.

By turbor

Hero (520)

30-08-2007, 08:34

There is some platform specific code in openMSX.
Some are obvious like file locations (/home vs 'My Documents', '/' vs '\') and others are related to slightly different behavior of the libraries between *nix systems and win32 environment. (full screen mode code is an example) or simply because some concepts do not really exist on win32.

It is mostly because of the later two that we need a real win32 developer that can debug these kind of unforeseeable effects/glitches

By Manuel

Ascended (19469)

30-08-2007, 11:02

There is very little platform specific code, but there is some. Also, the libs we use have platform specific code, obviously. So, sometimes things break on Win32 and that needs to be investigated. This requires someone who's willing to hunt down such a thing (with the help of the other devs, of course). Spotting these problems timely is a good thing, otherwise all kinds of shitty problems creep in. This is why we need structural support. One or two days a week to build and test it, would be enough. But around release time and when these platform specific problems face the surface, some more time is required.

By Vampier

Prophet (2413)

30-08-2007, 16:16

What happened to the previous win32-openMSX-staff anyways?
They got run over by a bus.

By yakumo

Expert (75)

30-08-2007, 19:56

Are you kidding?

By mth

Champion (507)

31-08-2007, 01:39

Don't worry, BiFi is fine, he just doesn't want to do the release.

We need four things for openMSX on Windows: testing, packaging, debugging and programming.

Testing is covered well by BiFi, Vampier and several other people (for example, Wolf tested the new audio features). Of course more testers is always better, but this is not where the problem lies.

Packaging (compilation of release binaries, making ZIP and installer) is not covered anymore. We haven't had an official Windows packager since tcm1998 retired from openMSX, but BiFi filled in as a packager for the last few releases. This position is the most urgent, since many users would appreciate a Windows binary of openMSX 0.6.3.

Debugging is needed when there are bugs in openMSX that only occur in Windows. Sometimes these are bugs in Windows itself, sometimes bugs in the cross-platform libraries we use, sometimes bugs in the Windows-specific code in openMSX and sometimes bugs in the shared code in openMSX that happen to be critical only in Windows. What we need is someone with a bit of programming skills (being able to read C/C++ and add debug prints is sufficient) and a lot of tenacity (some of these bugs take a lot of effort to pinpoint). Currently, if a Windows specific bug is found, we just hope either someone will find the cause by pure luck or someone will eventually get fed up with it and start digging to find the cause. That creates a lot of uncertainty. It would be good to have someone we can rely on, so we know that Windows-specific bugs will be looked into.

Programming is needed to add Windows specific code. For example, it would be nice to be able to use real floppies in openMSX. I heard this would only require a specially formatted file path, but there is no-one to implement and test that. It would be good if we would have someone to fill this position, but if it remains unfilled that is not a major problem. It just means that openMSX on Windows will only have the features that depend on nothing more than the cross-platform libraries provide.

So what we need as a structural solution, is at least a packager and a debugger. This does not necessarily have to be the same person.

Cross-compilation might make the job of a packager a bit easier, but for example testing the installer still has to be done on Windows. The debugging certainly has to be done on Windows. WINE is not really an option, because it does not behave exactly like Windows, so it cannot reliably be used to reproduce bugs that only occur on Windows. Tiny details can make a difference: there have been problems that occur only on one particular version of Windows.

Running Windows in a dual-boot or VMware setup would do the trick from a technical point of view, but we don't have anyone in the team who wants to do this. I don't want to speak for others, so I'll explain my reasons. The Windows license is one obstacle: I prefer to run only software for which I have a legal license and I don't want to pay Microsoft anything since I really dislike the way that company conducts its business. Also, I'm not eager to spend time learning the technical details of Windows. Since it is a platform that I don't run myself, I'm not motivated enough to spend the time required. Finally, I'm already doing most of the Linux support and about half of the OS X support (BouKiCHi does a lot too, fortunately), so I'd rather have some time left for programming actual features instead of working only on building and packaging.

There is hope though: in the last days, the combined efforts from hap (enen), diedel, manuel (Quibus), BiFi, BouKiCHi and myself have led to several Windows-specific issues being fixed. However, there is at least one critical bug left. Also, it remains to be seen whether this will evolve into a structural solution (hap: you, perhaps?).

By Vampier

Prophet (2413)

31-08-2007, 06:06

http://members.home.nl/parkel/openmsx-0.6.3-rc1-win32-bin.exe

Please test and give some feedback! :)

Some features in catapult don't work yet because this catapult is outdated.

By Manuel

Ascended (19469)

05-09-2007, 09:35

Please check this: http://www.msx.org/forumtopicl7746.html for a complete beta version. Note: we're still looking for structural help.

By Manuel

Ascended (19469)

22-10-2007, 12:07

OK, we still don't have a structural Win32 maintainer. But, in the mean time we tried to make compiling openMSX for Windows as simple as possible. The current openMSX source code should be compilable by almost everyone who has basic technical computing skills (you need to know what source code is, e.g.).

Please try out the instructions we put online here and let is know if you're successful or not.

Note: it's quite important to follow those instructions carefully, or things may not work. There's no superfluous information in it, I think :)

I hope this makes it more attractive to join our team!

By Manuel

Ascended (19469)

29-11-2007, 22:20

Apparently not. Still no solution. This probably means that 0.6.3 will be the last Windows release. Sad but true.

(We don't even have someone who's both on IRC regularly and building/testing openMSX on Windows regularly (e.g. once a week.))
Let alone build it for releases or worse: help solving Windows specific problems (no critical ones pending at the moment, though).

By AuroraMSX

Paragon (1902)

01-12-2007, 10:35

Manuel, you're being too pessimistic: look at the response over here :)

By Manuel

Ascended (19469)

27-08-2015, 15:33

Thanks to the autobuilder of Vampier, the 'regularly build' stuff has been solved.

But we still do not have a Windows oriented C++ developer in the core team. We know some people whom we can ask questions, and we are very glad for this. But it would be so much better if we had a Windows C++ developer core team member!
Especially for our plans to migrate off of SDL, this would be extremely valuable.

Anyone interested?

By PingPong

Enlighted (4140)

29-08-2015, 18:06

Hi !Manuel , Maybe.... what do you mean for migrating off sdl? What cross platform libraries do you use?
If a serious debug should be done , one need visual studio for building. As we know c is 'the same' (almost) but build is not.
Some one tryed building with m$ tooling ?

By Vampier

Prophet (2413)

30-08-2015, 02:19

PingPong openMSX compiles fine on Visual Studio (Express) we just need some help to get away from SDL.

By Manuel

Ascended (19469)

30-08-2015, 10:09

And to help debug and solve Windows specific issues.

As Vampier said, you can make full use of all Microsoft's Visual Studio tools. Actually, one of the topics is migrating to Visual Studio 2015, as it offers better C++11 support.

By PingPong

Enlighted (4140)

30-08-2015, 23:34

Thx i will evaluate if my spare time allow decent collaboratiin. I also try to download & build myself openmsx

By Manuel

Ascended (19469)

04-09-2015, 09:44

OK, if you need any assistance, please let me know.

Uncertain future for openMSX's Windows version

Share

Related content

Comments (36)