What's new

Windows Port

nmn

Mupen64Plus Dev.
Sorry, It is not done yet. This is discussion of it.

1. I will be submitting code soon today. I made a crude port but then realized I wanted to improve the code organization more.
2. The windows port will probably lack a GUI initially.

So far, I had gotten it to build but not run. However, I want to quickly rewrite the port now that I know what must be done.

Anyways, Suggestions on things I should be aiming at? Should we just throw up the GTK GUI initially?
 

X-Fi6

New member
Yeah initially you should use GTK for the Windows port as to avoid confusions between the Windows port's GUI and all other OS's GUI.

Apart from that I don't really know what you should be aiming at. I want the Windows port to stay alive because after all Mupen64 stands for Multi Platform Emulator for n64 and without the Windows port it doesn't feel like it's complete.

It's also a great base for curious people to code in their own stuff that they would personally want. Without a Windows port they can't do that.
 
Last edited:

Danny

Programmer | Moderator
Sorry, It is not done yet. This is discussion of it.

1. I will be submitting code soon today. I made a crude port but then realized I wanted to improve the code organization more.
2. The windows port will probably lack a GUI initially.

So far, I had gotten it to build but not run. However, I want to quickly rewrite the port now that I know what must be done.

Anyways, Suggestions on things I should be aiming at? Should we just throw up the GTK GUI initially?

I think the aim should be on keeping the Linux fixes current with the Windows build. All those core & plugin updates and new features should defiantly be in the Windows build too.

Why not just use the Gui from V0.5 nmm?
 
OP
N

nmn

Mupen64Plus Dev.
The old GUI would work but it would require too much change.

BTW, the port should allow us to merge into the latest version so that we will always be current with updates.
 

Richard42

Emulator Developer
So far, I had gotten it to build but not run. However, I want to quickly rewrite the port now that I know what must be done.

Anyways, Suggestions on things I should be aiming at? Should we just throw up the GTK GUI initially?

For the sake of simplicity it might be best to just use a cross-platform GUI system (either the GTK or KDE code) on Win32 instead of adding yet another gui framework to support. I don't know how badly it would impact the installer though.
 

Richard42

Emulator Developer
BTW, the port should allow us to merge into the latest version so that we will always be current with updates.

This depends on how the port is built. If it's written in a way which clutters up the common code with #ifdef WIN32s then it's going to live in its own branch and someone will be responsible for merging patches back and forth. If the changes are clean then I'll merge it into the trunk. If it the Win32 port adds a new Win32 GUI, then someone will have to keep the GUI code up to date as features are changed and added. But if it's written to use one of the pre-existing platform-independent GUI libraries, then it may be able to be fully integrated with the existing software, with very little maintenance required as we go forward..
 
OP
N

nmn

Mupen64Plus Dev.
If it's written in a way which clutters up the common code with #ifdef WIN32s then it's going to live in its own branch and someone will be responsible for merging patches back and forth. If the changes are clean then I'll merge it into the trunk.

It should be clean enough, there are a few ifdefs but it uses another macro that is defined by the CFLAGS in a seperate file. The reason is Cygwin may allow using the POSIX-like interface from inside of Windows. I had to split main.c, main.h, plugin.c, plugin.h, volume.c, and volume.h. Most of main.c and main.h are intact in the main/ directory but the remaining non-platform independent parts are seperated, and plugin.c plugin.h, volume.c, and volume.h are completely split.

The initial crude port was not good enough, So I went toward this idea.
 

sultanoswing

New member
A tad off topic, but as a linux fan, it tickles me pink to see discussions hoping software will be ported to windows, rather than from it. Welcome to the future, people :)
 

mudlord

Banned
but as a linux fan, it tickles me pink to see discussions hoping software will be ported to windows, rather than from it. Welcome to the future, people

And way to show GNU zealotry there....>.>

Sheesh.

This is EXACTLY whats turning me off from using Linux altogether, is people like you.
 

Slougi

New member
And way to show GNU zealotry there....>.>

Sheesh.

This is EXACTLY whats turning me off from using Linux altogether, is people like you.

Huh? I don't see the zealotry.



Anyway, I hacked on this a few days back. The KDE interface compiles fine, the core does need some work. So, if you can land the core changes we might get mupen64plus feat. KDE gui on windows ;) I don't know how easy deployment currently is though.
 

Richard42

Emulator Developer
And way to show GNU zealotry there....>.>

Sheesh.

This is EXACTLY whats turning me off from using Linux altogether, is people like you.

I would classify that particular comment more as "rooting for the underdog" than zealotry. We all have our own faults, though: Linux users are more prone to arrogance regarding a feeling of superiority, while Windows users are more prone to arrogance at the ubiquity of their platform. Hell, when Mupen64 was first developed Multi-platform was sort of a euphemism for everything outside of Windows, because most people assumed that all software ran on Windows. :)

In the end it comes down to each individual's comfort level with software. I have a friend at work who used to be a fairly big Windows fan and do some Linux bashing from time to time. He recently had to setup a new Linux machine because his project supports Linux in addition to Windows and he needed a Linux system for development and testing. He told me that he has been surprised by the quality of the software and likes working in Eclipse quite a bit.

Personally I switched to Linux a couple of years ago just because of software acquisition issues. There is so much more high quality software available for free in the open source world, and I was tired of having to pirate everything because office costs $200, photoshop costs $500, etc. Everybody wants to get paid in the Win32 world, even for crappy little shareware utilities -- there's no community sense of building a better future for all users and developers - it's more like "I gotta get mine".
 

mudlord

Banned
We all have our own faults, though: Linux users are more prone to arrogance regarding a feeling of superiority

Yeah, and that was were I sensed the zealotry in the offending user's post.

Personally, I find such vocal evangalism for Linux disturbing. Thats why I don't really want to use it full time, because simply, I don't want to be personally associated with a community that seems to me that continually touts its OS as the only thing to solve the world's problems, and the best thing since sliced bread.

Like, I want to make my own choices when it comes to software, and not have others force thier opinions. But anyway, this is getting seriously OT..
 
Last edited:

vision

New member
So, if you can land the core changes we might get mupen64plus feat. KDE gui on windows ;) I don't know how easy deployment currently is though.

As far as I know, it's a lot easier to either pick GTK or QT (which is the toolkit that KDE uses, latest major release 4.x compiles on Windows, this is the first major version number to do so) and then stick with one or the other, as opposed to having a Linux version in GTK and a Windows port in QT. They're two completely different toolkits, and one or the other (probably the Windows port) would fall behind in upstream changes.

Both GTK and QT compile on Windows now, but where Mupen is already interfaced in GTK, well.. :) Although, Tillin9 is working on a QT port..

Lots of great Linux apps have been successfully ported to Windows in GTK, including Pidgin and GIMP. Personally, I enjoy both toolkits, they each have their strengths and weaknesses.

Side note: in Linux, QT 4 draws faster than GTK 2 most of the time. But I have no idea if that's the case on Windows.
 

MasterPhW

Master of the Emulation Flame
Are there also plans in providing a 64bit binary for windows or are most of the 64bit changes linux specific? Because I know, windows handles 64bit in a very different manner than linux, so just a question.
Btw: I am really looking forward to the first MupenPlus RC on windows! You all had done a great job! =)
 

Slougi

New member
As far as I know, it's a lot easier to either pick GTK or QT (which is the toolkit that KDE uses, latest major release 4.x compiles on Windows, this is the first major version number to do so) and then stick with one or the other, as opposed to having a Linux version in GTK and a Windows port in QT. They're two completely different toolkits, and one or the other (probably the Windows port) would fall behind in upstream changes.

Both GTK and QT compile on Windows now, but where Mupen is already interfaced in GTK, well.. :) Although, Tillin9 is working on a QT port..

Lots of great Linux apps have been successfully ported to Windows in GTK, including Pidgin and GIMP. Personally, I enjoy both toolkits, they each have their strengths and weaknesses.

Side note: in Linux, QT 4 draws faster than GTK 2 most of the time. But I have no idea if that's the case on Windows.

*cough* Please read the Qt/KDE gui thread.
 

Richard42

Emulator Developer
Are there also plans in providing a 64bit binary for windows or are most of the 64bit changes linux specific? Because I know, windows handles 64bit in a very different manner than linux, so just a question.

The hardest part of the 64-bit port (the dynamic recompiler) is platform-agnostic and would only require a few small changes to work. The C code however was not written with Windows in mind and would require significant changes to work in Win 64. There are currently no plans to add support for 64-bit windows.
 

MasterPhW

Master of the Emulation Flame
The hardest part of the 64-bit port (the dynamic recompiler) is platform-agnostic and would only require a few small changes to work. The C code however was not written with Windows in mind and would require significant changes to work in Win 64. There are currently no plans to add support for 64-bit windows.
What a shame... but we'll see, what the future will bring! Probably you will find some more windows devs, which will take the win64 part.
 

Tillin9

Mupen64Plus Dev.
Not sure whether that was a cough over the KDE==Qt issue or over credit. FYI: Slougi deserves all the credit with the KDE GUI. My real job lately has been hellish, and the current KDE4 GUI is much more complete than anything I whipped up, so I basically dropped my (more or less KDE3) GUI and when I have time will try to extend the current KDE4 GUI (i.e. configs for plugins, etc.).
 

Top