As far as I know using “winecfg” you can uncheck the linking of home directory to windows user directory. This way damage can only be done to the wine user directory but not home directory in general. Not sure though if wine still allows accessing host file system without those links.
1 Like
Wine maps / to a windows disk by default. Even if it doesn’t however it does allow executing native applications from windows applications which can see the host filesystem normally, don’t expect any inherent security by unchecking those links.
edit: you would probably want to employ some OS isolation like a chroot, but that would have to be carefully checked also (on linux you can break out easily, on openbsd not so much, and even then you can still send BMessages to running servers and get them to do potentially destructive stuff)
1 Like
Wine doesn’t prevent programs from making system calls, so you can hardly rely on sandboxing MS-Windows programs by relying on Wine alone.
2 Likes
Impressive progress from @X512 and @waddlesplash .
18 Likes
Notepad++
38 Likes
I like and use Notepad++ on Windows…
But Koder is as good to use for my needs…
4 Likes
Do you manage to get my favourite Markdown editor Typora running and Darktable for RAW photo editing?
It looks really nice indeed for being emulated software. I prefer the look over QT applications, which usually looks quite “linuxy”.
A little off topic, but i like the look of old System 7-9, Windows 2000 and Haiku (Haiku looks way better than BeOS, more polished). Modern UI not so much, with the exception of Mac OS 10.6 up to about 10.9.
Keep up the good work!
1 Like
so now firefox and chrome will work long before firefox and chrome port? 
7 Likes
I gave a quick look to your changes and I would like to suggest a small trick to simplify things.
The preprocessor of GNU tools and CLang provide a keyword called #include_next.
Sometimes its usage is not recommended, but here it could be useful.
The purpose of this keyword is to include the next file with the same name into the current search order.
For doing a simple example, you patched few files with something like this:
+#ifdef __HAIKU__
+#define SIGIO SIGPOLL
+#endif
Since this change makes me suspect that SIGIO is undefined into the system headers of HAIKU, you can create a directory and call it for example haiku_wine_utils.
Inside this directory, create an include directory and then a sys directory inside include.
Finally, inside the haiku_wine_utils/include/sys, create a file called signal.h with a content like this:
#ifndef __HAIKU_WINE_UTILS_SYS_SIGNAL_H__
#define __HAIKU_WINE_UTILS_SYS_SIGNAL_H__
#include_next <sys/signal.h>
#define SIGIO SIGPOLL
#endif // __HAIKU_WINE_UTILS_SYS_SIGNAL_H__
Now, when you configure WINE, you can add to CFLAGS the path to the tree that you just created with an option like -I~/haiku_wine_utils/include (obviously, the right path must be used here).
That’s all.
Now, every time the sources will be compiled, the first sys/signal.h to be included will be the one that you just created, which will call the system header as first task, thanks to #include_next keyword. Then, it will provide the definition of SIGIO that will be needed by the sources of the framework.
The same trick can be used for emulating other macros that you wrapped with some #ifdef...#endif, like ESOCKTNOSUPPORT/CS6/CS7/CS8/etc…
This could allow to simplify the number of changes and perhaps, if some fixes will be accepted into the codebase of WINE but others not, it can allow to create a package “haiku_wine_utils” that provides some utilities and sources to be used at compile time and without touching the main core of WINE.
You could also “patch” the library functions actually. If you want to “adjust” the behaviour of ioctl() function, you may add another file like this one:
#ifndef __HAIKU_WINE_UTILS_SYS_IOCTL_H__
#define __HAIKU_WINE_UTILS_SYS_IOCTL_H__
#include_next <sys/ioctl.h>
int haiku_utils_ioctl(int __fd, int __cmd, ...);
#undef ioctl
#define ioctl haiku_utils_ioctl
#endif // __HAIKU_WINE_UTILS_SYS_IOCTL_H__
And, inside a sources that is compiled and added to LDFLAGS of WINE at configure time, you can handle some extra commands not handled by current implementation.
I don’t know how many changes will need WINE to be fully supported on HAIKU.
Perhaps, the number of fixes won’t be so huge.
However, WINE is a software constantly evolving and every time a new version will be released, then an updated patch will need to be prepared, kept up to date and this is a job that somebody will need to do.
Instead, the “utils” will make you free from doing this.
What do you think?
Sincerely.
14 Likes
Remember that Wine is not an emulator… it’s an implementation of the Windows API for other OS’s so if we could run Firefox for Windows on Wine, it would run natively. There’s no shame in running software through Wine.
An actual port to Haiku would be preferable but if this allows me to run Inkscape on Haiku, then I’ve got all but two of my necessary applications on Haiku… the last two being OpenVPN and actual virtualized VM’s through Qemu or Virtualbox.
I’m getting my new workstation on Thursday and the first thing I want to try is to run Haiku on it. The prospect of having a near complete workstation experience on Haiku is amazing. Thanks for all the hard work!
8 Likes
If games through wine were to take off on Haiku (which I just learned about the other day through Hacker News) I would be so excited. I already am excited, to be clear - I would probably be over the moon itself with excitement if another OS steps up and can play some games.
I’m going to research, but is hardware acceleration the main hurdle after wine is properly ported? I am more than happy to get involved and test if/when the time comes.
Thank you for doing work on this!
2 Likes
@spinningd20 see Vulkan lavapipe software rendering is working on Haiku
Essentially: GPU acceleration is in progress and showing some pretty nice results for radeon cards (the title of the thread is a bit misleading because hardware rendering is now working).
And for playing games in wine on haiku… AFAIK yeah I guess you need wine and hardware 3D acceleration. I think it will be a bit of time yet before these WIP features reach users though. It’s a very exciting time to be using haiku!
2 Likes
I suspect that if these two projects, wine and hardware acceleration, reach a good progress, there will be a mass transfer of new users who will arrive from both sides, both from linux and from windows and from mac, perhaps for different reasons … but tired of both windows and linux and mac
5 Likes
It certainly sounds that way reading hacker news. There are still quite a few rough edges in haiku but it’s really picking up momentum… 2022 should be even better for haiku than 2021 was!
8 Likes
If the Wine port matures before 3D acceleration, you might still be able to use the Windows version of SwiftShader to get some mid-2000 D3D9 games running. It will look a bit choppy, but still really cool to play around with (and quite playable if you’re not too picky) as we wait for 3D acceleration.
1 Like
Last I saw benchmark numbers, Mesa LLVMpipe was generally more performant than SwiftShader, so it may not really matter.
3 Likes
Just wow @X512 and @waddlesplash - you’re doing amazing work 
8 Likes
LLVMpipe is for OpenGL. It could be paired with Wine’s D3D9 → OpenGL wrapper though. Lavapipe paired with DXVK could also be something to try.
Shouldn’t Wine’s D3D9 → OpenGL wrapper be the default anyway, since that is what would be able to use hardware acceleration once it is available?
Anyway, the recent developments in the project are amazing. Wine and Xlibe will allow so many more apps to run on Haiku that it opens up many more possibilities to use it as a main system for more people.
1 Like