I’m aware, it seems most of the fixing is in the coding style and coding errors from newer c++ standards. Not to mention, lots of functions in windows has been added since the original creation of this, and currently, most windows functions are just stubs. It would be nice to have as it seems it would integrate quite well into Haiku and seemingly would be lighter than wine.
2 Likes
I suppose wine cqn help eventually for this, no?
Been there, done that back in the BeOS days. WINE is completely reliant on X11. So you first have to have a perfect X11 port, then you port WINE on top of it, then you run the Windows libs, and only then can you run Windows programs. Can you say … slow. Besides, we had an X11 port back in the days, but it never worked well.
So, yeah, I just tried to do some work on that ExeCoffSky program.
I doesn’t even compile in it’s current state, too bad.
I would like to start a revival project, but right now, I need to get it to compile.
My roadmap right now is as follows:
- Get the japanese text translated into english.
- Get the program in it’s current state to actually compile.
- As Windows is a moving target choose ONE Windows version to emulate for now(probably Windows 2000).
- Get 100% of the Windows API functions put in as stubs, so when I try programs, I can see what functions need implemented to make them work.
- Actually implement these functions so that Windows programs actually work.
Ok, sorry for the posting twice, but…
I got the README translated, it has errors from Google Translate, but it does offer some insight into the operation of the program, and how it does things.
Also I am working on compiling.
It still does not compile of course, but these should be of use to the Haiku developers.
It says that “B_OK”, “B_ANY_ADDRESS”, “B_NO_LOCK”, “B_READ_AREA”, “B_WRITE_AREA”, and “B_PAGE_SIZE” are undeclared.
I am not sure if they are just not seen by the compiler, not included in the source code, or just no inplemented in Haiku.
If it is an ExeCoffSky source issue, fixing it will go a long way towards getting it to work.
If it is a compiler or Haiku issue, fixing it will go a long way towards getting this an many other BeOS programs running.
EDIT: Okay the the undeclared functions have been fixed, I just had to include kernel/OS.h
Before you continue, I’ve already allowed it to build on x86, check my repo:
Supposedly, but from what I’ve heard, there’s incompatibility with how Wine works down to the kernel level of Haiku.
Cool, looks like I should have done more googling before posting LOL.
I have compiled the one from your GitHub, but when I run Win32_Server, it says missing symble HandleToImage, how do I stop this from happening.
I think that if we can work together, we might be able to come up with a working solution, at least for old and simple Windows apps.
I’m actually still working on that…It seems that some functions aren’t defined correctly in headers, or don’t exist at all. This is probably since a different c++ standard was used when this was originally being coded. I have some code getting past that message though each time I patch a missing symbol message, a different one appears, so it may be a while before getting past that stage of “missing symbols” in the libld_dll.so library, which contains pretty much all the functions.
Maybe, but that would require vulkan which we definitely don’t have at the moment.
Uh, no, not really. WINE actually has an (outdated) page on getting it to run on Haiku: Haiku - WineHQ Wiki
It seems the most important things are some crucial POSIX functions that we haven’t implemented yet (pthread setstack, etc.) and the address space layout model. Neither of these is a “kernel level incompatibility” per se (though fixing them will indeed require changes to the kernel). So it’s mostly a matter of time and effort.
1 Like
Well, the address space layout would be the main problem here (the other things we can easily, or have already, fix). Wine on Linux makes use of the fact that the address space layout is largely the same between Linux and Windows. We could switch to a similar layout, but that would reduce the kernel space to 1GB (vs 2 currently), and may create some problems because we do a lot of things in the kernel.
However, this problem does not exist on x86_64, where everyone uses the same layout. So maybe port Wine to 64-bit Haiku first?
2 Likes
That’d be a good idea, then ExeCoffSky could be an option for x86_gcc2 and x86?
1 Like
but to ExeCoffSky is need at less 20 years to get the wine mature, dont you think?
True, wine has taken lots of time to evolve and many people to develop. I guess then ExeCoffSky would only be a backup option if wine isn’t portable to x86_gcc2 and we have the necessary man power. (x86 doesn’t matter as much as I heard only x86_gcc2 and x86_64 are officially promoted for the beta release.)
maybe a native api support can be better for haiku in performance terms ? and with help from wine it can be more quick maybe a fusion between execoffsky and wine,… i dont really know.
Right now, I think ExeCoffSky is a better solution for us than WINE, mainly because the CodeForEvolution version actually compiles.
What we need right now is to get it to run without symbol errors, then we can implement functionality.
Stubs for all or most Windows system calls/functions would be nice, the stubs will just return an error value, and put up a dialog that says something like “Function X in Y.dll is unimplemented, parameters are Z”. From there we could get programs working one-by-one just by going through and creating implementations of the functions that they use, we would start with very simple programs obviously.
1 Like
Okay, sorry for reviving a dead thread.
I cannot seem to get the experimental branch of ExeCoffSky to compile.
If I can get it to compile again, then I have an idea for it.
I haven’t worked on that branch for quite a while, mainly because completing it would take a lot of time and there is already a free, open source operating system targeting to be completely compatible with Windows called ReactOS. That doesn’t mean that ExeCoffSky is dead, just it’s out of my scope and others are welcome to look at the experimental branch to fix it up.