Does anyone still use dos zsnes?

[Noxious Ninja]

I assume *nix version will depend on an installed libsdl package, and the Windows version would ship with SDL.dll

[grinvader]

I assume *nix version will depend on an installed libsdl package

It already does. Currently zsnes requires libsdl >= 1.2.0 .

and the Windows version would ship with SDL.dll

Most likely. SDL is free, after all.

[gaijinx1]

Face it. Zsnes is the best Snes emulator out there. In terms of compatibility, it is superior to others and the GUI is the best.
Just release Zsnes 1.40 someday

[Oblivion]

There are aspects of Snes9X that are better than Zsnes, and vice versa. I happen to prefer Zsnes, but both are good emulators. Also, SNEeSe and Super Sleuth probably have better timing than either Snes9x or Zsnes.

[jdratlif]

How will SDL effect netplay? I assume that the DOS, Windows, and *nix versions would be inter-compatible.

Will I be required to install an SDL environment, or is the SDL environment attached to a different executable for each OS?

SDL should have no effect on netplay at all. If I understand right, Netplay is implemented using native sockets via the BSD socket API (which winsock provides and every unix implements), and does not use wrappers, such as wxWidgets provides.

I would expect a change from DX to SDL, wxWidgets, or GTK (etc. al) would only affect input, sound, and video. If those effects are noticeable or not, I cannot say.

[Nach]

For netplay, we'd probably use my socket library which I'm cooking up. It basically acts just like normal sockets, but hides the specifics of winsock, and does some automatic cleanup.

[Kagerato]

I misspoke. I shouldn't have said windowing toolkit as much as some way of addressing the screen. You must provide the "screen" that OpenGL draws on. In general, this would be a window system API such as X or Win32. I see no real reason why OpenGL couldn't run in DOS, but I have never seen anything related to this.

I see no reason either, but there seems to be no implementation.

The real point is that DOS has no windowing API of any sort. The screen is accessed directly through the video hardware for traditional DOS applications. You don't need any kind of programming interface to directly access hardware.

Accelerated hardware display is capable through OpenGL. But you can draw on a window in SDL without OpenGL. Read the SDL docs if you don't believe me. You specifically have to enable OpenGL to access the OpenGL system. But you are not required to enable it. So, SDL could be slow, provided you are not using accelerated hardware support via OpenGL or some such similar method.

One part of being a multimedia library is video. Video cannot exist without some screen to draw on. One of the things SDL provides is a screen. Win32 native APIs are also screens, as are the X11 windowing system.

The screen is an underlying, lower-level concept which the windowing system builds upon. SDL does not contain a windowing system or a GUI toolkit, which is contradictory to what you originally said.

SDL (and OpenGL) can be used to draw on a framebuffer. The framebuffer is providing the screen there, not SDL.

I did not mean to imply that DX was the windowing system + the widgets + the mm system. Only that if you take advantage of DX (native to win32), you are likely to do the same with regard to widgets and the windowing system.

I'd certainly like to hear the case of why that is advantageous. In my opinion, that creates unnecessary levels of dependence, and removes the programmer's freedom to choose what interfaces they desire to work with.

That's not what I said at all. I am talking about the application frame. What contains the application. Not the GUI, not the widgets, not what's drawn inside the frame. Just the frame. This is window system dependent. SDL wraps the Win32 interface on Windows, and the X11 interface on X systems.

You're correct.

From what I have seen on the GTK+ website, gtk is a windowing API (wrapper to native systems such as X) and a widget toolkit. I am basing this on the fact that they have a hello world program that creates a window using GTK. That window is the frame.

I phrased it rather poorly. GTK probably does contain an implementation of window frames (though I am not certain). My response's purpose was to state that GTK is mainly a widget toolkit.

A window manager does just what the name implies, it MANAGES windows. It does not create them. If it did, every X application would have to be tailored for every window manager, unless by some astonishing coincidence they all decided to use an identical API. It provides nice little decorations and placement tools, but does not create windows. Xlib does that.

You have obviously never seen an old X11 application.

I wish I still had my first edition RedHat Linux unleashed book. It had example programs written in Xlib. They were horrible. But it's no worse than writing a Win32 application without MFC or the windows widgets.

By technicality, you win. X11 creates the '"window", but this "window" is nothing more than a rectangular area on the screen. Everything that is normally associated with a window, including its appearance and interface, is left to the window manager.

I think my meaning was obvious. You can't run X programs without an X Server. If you don't have an X Server, you don't have X applications. Native X11 applications will not run under Windows. You are describing them running under X Windows which happens to be running in Windows.

This seems equivalent to saying I'm running Nesticle in Windows XP if I run Windows 98 under vmware and run Nesticle in the virtual machine. Nesticle does not run in Windows XP. Just because Windows XP happens to running underneath vmware underneath Windows 98 does not imply that Nesticle runs under Windows XP.

I'll agree because I interpreted your original comment too literally.

Cygwin is an emulation layer. It is not a cross-compiler. You might cross-compile on cygwin, but this is not the purpose of cygwin. The purpose of cygwin is to provide a wrapper for POSIX system calls (and related bric-a-brac) in Windows. It is an emulator in much the same sense that zsnes is an emulator.

Cross-compilation compiles an application for another system on your system. Like compiling calculator programs on Windows, or compiling NSRT DOS on Linux.

I understand the function of Cygwin and the concept of cross-compilation. I apologize for associating the two without proper distinction.

"Native apps are not portable. Take a look at the zsnes source code. Note the zloader.c programs. There's one for the Windows port, one for the DOS port, and one for the SDL (Linux) port."

I don't think you've read or understood what I said at all.

I'm talking about native windowing systems.

Native application and 'application which exclusively accesses a particular windowing system' sound nothing alike.

SDL wraps Win32 in the windows port, and X11 in the Linux port. So an SDL app will run in both, if you write to SDL.

I understand portability via source compilation.

But the same app w/o SDL has two versions, the X11 window API version (or whatever wrapper you use above that, Xt, gtk, motif, etc) and the Win32 window API version.

It doesn't have two versions; it's the same program. What you mean to say is that there is a compilation branch. Only a certain set of the source files is compiled for a particular system.

You can argue with me on the technicalities of the word version, and you'd win. There's a bigger point I'm trying to make here.

C programs for unix are rarely designed for an operating system in the way a windows program is designed for Windows.

This makes little to no sense at all. Many programs for unix-like systems rely on the presence of other libraries. It's very, very difficult to find a program that doesn't unless you resort to naming the low-level interface libraries themselves.

Whether the libraries involved deal with user interface or not is entirely irrelevant to the point (which lays below).

Unix portability is also a myth. It may be largely similar, but there are big differences. Why do you think things like Imakefiles and configure scripts exist?

The purpose of the configure script is to initialize the appropriate variables of the environment (target system).

The purpose of the makefile is to compile the appropriate source files, branching as necessary to handle variances in the environment.

You also seem to think that native means processor. I never mentioned processor and nothing I said has anything to do with that.

I would say you do not fully understand the implication of the word 'native' in the context you used it. Native, in the context of programming, has traditionally been used to designate a program compiled to a particular processor instruction set. This is juxtaposed with the idea of interpretation, where the program itself is never stored on disk as native processor instructions.

My response to the way you used the word is somewhat common now. Usage of the word native as you particularly applied it is meaningless, and has been criticized as such for some time. There are far clearer ways of describing what you meant to say.

The overall point, if you have not yet understood it, is that there is such a being as the compiled program which is portable, via source, to many different systems. UNIX/C-style portability is not a myth. It has been functionally effective for many years now. "Write once, compile anywhere" is the myth, and rightly so: it's an impossible-to-fulfill generalization ('anywhere').

You explicitly said that a native application, that is, a compiled application (for no other meaning is at all clear from your original statement) is not portable. The purpose of my response there was mainly to show the opposite is true. I was clearly not effective in that, because in your response you furthered the inaccuracy by stating that UNIX portability is a myth.

[jdratlif]

I misspoke. I shouldn't have said windowing toolkit as much as some way of addressing the screen. You must provide the "screen" that OpenGL draws on. In general, this would be a window system API such as X or Win32. I see no real reason why OpenGL couldn't run in DOS, but I have never seen anything related to this.

I see no reason either, but there seems to be no implementation.

The real point is that DOS has no windowing API of any sort. The screen is accessed directly through the video hardware for traditional DOS applications. You don't need any kind of programming interface to directly access hardware.

I suppose it was an oversight to state that OpenGL requires a "windowing system". But I did not mean to include DOS as one of the systems I was referring to. I was only talking about modern graphical systems such as X11 and Windows.

My point was that OpenGL cannot create Windows. Because OpenGL cannot create Windows (that being tied to the platform API (I'll stop using the word native since it seems to so confuse you)), you cannot use OpenGL without some API for obtaining such a window. I think you used the term framebuffer? That term will work.

One part of being a multimedia library is video. Video cannot exist without some screen to draw on. One of the things SDL provides is a screen. Win32 native APIs are also screens, as are the X11 windowing system.

The screen is an underlying, lower-level concept which the windowing system builds upon. SDL does not contain a windowing system or a GUI toolkit, which is contradictory to what you originally said.

SDL (and OpenGL) can be used to draw on a framebuffer. The framebuffer is providing the screen there, not SDL.

Bureaucrat Conrad, you are technically correct. The best kind of correct.

My point nevertheless remains valid. OpenGL cannot obtain a framebuffer by itself. SDL provides, however indirectly, that framebuffer.

I did not mean to imply that DX was the windowing system + the widgets + the mm system. Only that if you take advantage of DX (native to win32), you are likely to do the same with regard to widgets and the windowing system.

I'd certainly like to hear the case of why that is advantageous. In my opinion, that creates unnecessary levels of dependence, and removes the programmer's freedom to choose what interfaces they desire to work with.

I don't believe the phrase "take advantage of" is equivalent to the word "advantageous", but I will rephrase.

One who makes use of DirectX is likely to use other windows-only components such as the common controls and the Win32 windowing API rather than a platform independent solution such as gtk or wxWidgets.

I do not believe it is advantageous.

From what I have seen on the GTK+ website, gtk is a windowing API (wrapper to native systems such as X) and a widget toolkit. I am basing this on the fact that they have a hello world program that creates a window using GTK. That window is the frame.

I phrased it rather poorly. GTK probably does contain an implementation of window frames (though I am not certain). My response's purpose was to state that GTK is mainly a widget toolkit.

Take a look at the hello world example they have on the gtk site and tell me what you think.

I didn't run the program though.

A window manager does just what the name implies, it MANAGES windows. It does not create them. If it did, every X application would have to be tailored for every window manager, unless by some astonishing coincidence they all decided to use an identical API. It provides nice little decorations and placement tools, but does not create windows. Xlib does that.

You have obviously never seen an old X11 application.

I wish I still had my first edition RedHat Linux unleashed book. It had example programs written in Xlib. They were horrible. But it's no worse than writing a Win32 application without MFC or the windows widgets.

By technicality, you win. X11 creates the '"window", but this "window" is nothing more than a rectangular area on the screen. Everything that is normally associated with a window, including its appearance and interface, is left to the window manager.

I never said the window had to look a certain way or act in a certain manner. I only said OpenGL needed some window for drawing. And of course I should further restrict that to modern graphical systems such as X11 and Windows, not being applicable to DOS.

Native application and 'application which exclusively accesses a particular windowing system' sound nothing alike.

You are right. I will try to include greater specificity in my future posts.

C programs for unix are rarely designed for an operating system in the way a windows program is designed for Windows.

This makes little to no sense at all. Many programs for unix-like systems rely on the presence of other libraries. It's very, very difficult to find a program that doesn't unless you resort to naming the low-level interface libraries themselves.

What I am saying is, a program created in Linux is not tied to Linux in the same way that a program in windows is tied to Windows. Windows and Microsoft make it very easy to use the Windows platform API to create Windows, GUI widgets, and mm controls that are not portable. By contrast, a program created in Linux has few (if any) ties to Linux. You could probably compile most Linux programs (with a little work to sort out the differences -- if any there are) in most any other unice (provided we assume C or some other high level language).

Unix portability is also a myth. It may be largely similar, but there are big differences. Why do you think things like Imakefiles and configure scripts exist?

The purpose of the configure script is to initialize the appropriate variables of the environment (target system).

The purpose of the makefile is to compile the appropriate source files, branching as necessary to handle variances in the environment.

I was too liberal in my statement. I only meant to say that people largely believe that any C program will compile on any system (unix at least) without any changes. This is not true.

The configure script's greater purpose is to sort out the differences between various systems so the program will know what kind of a system it is compiling on. Should I use gethostbyname? It's deprecated, supposedly replaced by getaddrinfo, but Solaris 8 doesn't even have getaddrinfo in it's socket library.

I also did not say makefile, I said Imakefile. It's like a configure script and Makefile rolled into one.

You also seem to think that native means processor. I never mentioned processor and nothing I said has anything to do with that.

I would say you do not fully understand the implication of the word 'native' in the context you used it. Native, in the context of programming, has traditionally been used to designate a program compiled to a particular processor instruction set. This is juxtaposed with the idea of interpretation, where the program itself is never stored on disk as native processor instructions.

I do not agree with you at all here. You are claiming that the word native must refer in some way to a processor. This is an unnecessary restriction on the word native.

Native, in my context, was referring to a platform specific API tailored and created for an operating system. Native win32 API for windowing for example as opposed to SDL and GTK wrappers which are platform independent (on the API level at least).

My response to the way you used the word is somewhat common now. Usage of the word native as you particularly applied it is meaningless, and has been criticized as such for some time. There are far clearer ways of describing what you meant to say.

I would see your evidence here, should you have any that is.

The overall point, if you have not yet understood it, is that there is such a being as the compiled program which is portable, via source, to many different systems. UNIX/C-style portability is not a myth. It has been functionally effective for many years now. "Write once, compile anywhere" is the myth, and rightly so: it's an impossible-to-fulfill generalization ('anywhere').

My point, since you seem to be evading it, is that a program written using platform APIs such as Win32 or X11 for creating windows are not portable, on the source or any other level.

You explicitly said that a native application, that is, a compiled application (for no other meaning is at all clear from your original statement) is not portable. The purpose of my response there was mainly to show the opposite is true. I was clearly not effective in that, because in your response you furthered the inaccuracy by stating that UNIX portability is a myth.

I should not have made such extravagant claims. My toned down point is that write once run anywhere is a myth. On this I think we agree. Java doesn't have it, nor does C.

[jdratlif]

i'd perfer WxWidgets over gtk.

and SDL isn't really at the same level of functionality as DX. I think all the input improvements made with the switch to DX8 would be lost.

they intend it to be modular, so a native Win32 API GUI wouldn't be out of the question.

After looking into it, I agree. wxWidgets forever, baby!

Very easy to learn and pretty good docs, too. Not Javadoc good, but still pretty good.

[jdratlif]

For netplay, we'd probably use my socket library which I'm cooking up. It basically acts just like normal sockets, but hides the specifics of winsock, and does some automatic cleanup.

Why don't you use the BSD socket API instead of winsock extras?

Or, if you used wxWidgets instead of GTK, they have a socket library.

I really don't understand why winsock needs extras, or why wxWidgets needs a socket library. Why not stick to the BSD socket API. Every OS implements it. Unix, Winsock (unless you start using the windows add-on functions), Mac...

[Nach]

For netplay, we'd probably use my socket library which I'm cooking up. It basically acts just like normal sockets, but hides the specifics of winsock, and does some automatic cleanup.

Why don't you use the BSD socket API instead of winsock extras?

You don't seem to understand.

Winsock requires various calls before creating your first socket, and after closing your last one. You can't get around that on Windows.

Winsock also renames a function or type in it's library. Which is why a simple library over that to hide stuff makes life easier.

My library is just an OO socket, which hides a bunch of #ifdef __WIN32__ stuff from you, and has benefits of OO like auto cleanup.

It basically is the BSD socket API other than that.

Stuff like this:

Code: Select all

#ifndef __WIN32__
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <unistd.h>
#define closesocket(x) close((x));
#else
#include <winsock2.h>
#endif

Or this constructor code:

Code: Select all

  sock_t::sock_t(SOCKET_TYPES socket_type)
  {
    #ifdef __WIN32__
    if (existing_sockets.empty())
    {
      //Startup winsock
      WORD versionneeded = MAKEWORD(2,2);
      WSADATA wsadata;
      WSAStartup(versionneeded, &wsadata);
    }
    #endif 

Understood?

[jdratlif]

For netplay, we'd probably use my socket library which I'm cooking up. It basically acts just like normal sockets, but hides the specifics of winsock, and does some automatic cleanup.

Why don't you use the BSD socket API instead of winsock extras?

You don't seem to understand.

Winsock requires various calls before creating your first socket, and after closing your last one. You can't get around that on Windows.

Winsock also renames a function or type in it's library. Which is why a simple library over that to hide stuff makes life easier.

My library is just an OO socket, which hides a bunch of #ifdef __WIN32__ stuff from you, and has benefits of OO like auto cleanup.

It basically is the BSD socket API other than that.

Stuff like this:

Code: Select all

#ifndef __WIN32__
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <unistd.h>
#define closesocket(x) close((x));
#else
#include <winsock2.h>
#endif

Or this constructor code:

Code: Select all

  sock_t::sock_t(SOCKET_TYPES socket_type)
  {
    #ifdef __WIN32__
    if (existing_sockets.empty())
    {
      //Startup winsock
      WORD versionneeded = MAKEWORD(2,2);
      WSADATA wsadata;
      WSAStartup(versionneeded, &wsadata);
    }
    #endif 

Understood?

No, I am aware of the winsock initialization code and cleanup code. I have written networking applications for win32 and unix.

But what's wrong with using the defines?

I thought maybe you were using additional APIs included in winsock2 that are on top of the BSD API.

Looking at what you posted though, it looks like you are also making a C++ socket wrapper. That I can identify with. I've done that myself.

[Nach]

No, I am aware of the winsock initialization code and cleanup code. I have written networking applications for win32 and unix.

But what's wrong with using the defines?

It should be kept out of the main code using the sockets. Working with something should not worry about the implementation, it's the library that should worry.

I thought maybe you were using additional APIs included in winsock2 that are on top of the BSD API.

Don't see what use they really have, and that's not portable.

Looking at what you posted though, it looks like you are also making a C++ socket wrapper. That I can identify with. I've done that myself.

I think I already mentioned it's supposed to be OO.

[jdratlif]

BTW: Have you considered allgro as an alternative to DX or SDL? I wonder how the win32 port works underneath...

I hadn't seen much that uses it recently since it was djgpp/DOS for so long, but I'm fairly sure one of the emulators I play uses it.

[ipher]

an emulator that uses Allegro? FakeNES. And Allegro can be used for win, dos, or nix

[Noxious Ninja]

KiGB also uses Allegro.