Элегантный способ сделать Far3 на *nix без адских трудозатрат

[unxed]

Description and implementation details of the new improvement

1. Чиним существующие баги, проявляющиеся под Wine (заодно в ReactOS наверняка спасибо скажут), если таковые имеются.
2. А потом понемногу добавляем в нужных местах Far использование под Wine прямых вызовов POSIX API — через либу winescape. Она позволяет из-под Wine дёргать POSIX как вам вздумается, там конвертер ABI и обёртки для всего, что нужно файловому менеджеру. Можно сделать поддержку chmod и всего остального, что через Wine нельзя реализовать нормально в принципе. Можно получить нативную скорость.

[johnd0e]

Я в этом не разбираюсь, но друг написал такое:

Details

1. Wine не гарантирует сохранность регистров и ABI
   Wine — это не виртуальная машина, а слой совместимости.
   Он может:

• менять регистры между вызовами;
• переключать стеки;
• перехватывать исключения;
• вставлять свои trampolines и thunk-и.

А библиотека рассчитывает, что после перехода из Win32 в Go/C она сможет выполнить syscall как будто работает в нативном Linux-процессе. Это уже риск.

2. Go runtime сам по себе агрессивен
   Go:

• перекидывает горутины между потоками;
• использует сигналы (SIGURG, SIGSEGV, SIGPROF);
• делает stack growth;
• может менять alignment аргументов.
• А libwinescape пытается встроиться в это и ещё поверх Wine — это двойная нестабильность.

3. Системные вызовы — разные на разных ядрах
   Даже Linux:

• меняет номера syscalls между архитектурами;
• меняет структуру stat, dirent, sockaddr;
• вводит новые флаги, убирает старые.
• FreeBSD/NetBSD — вообще другой мир.

4. Wine может менять внутренности в любой версии
   Это не публичный API.
   Если Wine завтра решит:

• изменить способ вызова ntdll.dll;
• поменять ABI перехода в Unix-слой;
• добавить sandboxing;

то libwinescape может сломаться без предупреждения.

🧩 Но почему это всё-таки работает?
Потому что Wine в конечном счёте запускает обычный ELF-процесс, и если:

• попасть в настоящий поток Linux,
• выполнить настоящий syscall,
• не трогать Win32-структуры,

то ядро не знает, что процесс «виндовый».

Это хак, но умный.

🛠️ Насколько это хрупко на практике?
Если использовать только файловые операции — довольно надёжно.
open, read, write, mkdir, rename, getdents64 — работают стабильно.

Если использовать сетевые вызовы — уже рискованнее.

Если использовать Go — ещё хрупче.

Если использовать многопоточность — зависит от Wine версии.

Обсуждать тут слова друга наверно будет жёстким оффтопиком, но сомнения всё же возникают.

[unxed]

И Windows ABI и syscall ABI POSIX — жёстко регламентированные стандарты. Если Wine не будет им следовать, он просто перестанет работать. Я просто сделал прокладку из одного стандарта системных вызовов в другой. То же самое, что делает сам Wine, только наоборот. Это не может просто так произвольно сломаться.

К go оно гвоздями не прибито: если посмотреть на репозиторий внимательно, там и для Си и для go поддержка реализована, с паритетом по возможностям. Сюда, например, я это принёс вообще вне контекста go, Far3-то на C/CPP написан.

Вот про многопоточность да, резонный тейк, тут я буду тестить это всё ещё.

И чуть подробней:

Критика в основном справедлива как общее предупреждение о хрупкости raw-syscall-трюков под Wine, но большинство пунктов не специфичны для libwinescape и уже адресованы в наших же материалах: (1) регистры/ABI/trampolines — реальный риск для произвольного Win32→native перехода, но не для голого SYSCALL из обычного .text, который Wine's JIT/exception-машинерия вообще не ожидает увидеть и потому не трогает — именно это уже задокументировано в FUTURE-IDEAS.md §3.4 как "легче кейс, чем полный unwinding/exception story", а не как решённая проблема; (2) syscall-номера/структуры между ядрами/архитектурами — это не критика самого трюка, а обычное требование platform-specific таблицы syscalls, ровно то, для чего в спеке уже настояно на "маленькой явно перечисленной таблице с номерами из ABI-документации, никогда не выдуманными"; (3) "Wine завтра сломает ABI без предупреждения" — верно и честно, это genuine fragility любого недокументированного трюка, стоит явно фиксировать как риск, а не замалчивать. А вот что касается многопоточности и Go-рантайма — тут я разделяю скепсис друга сильнее всего: Go's goroutine-to-thread scheduling, сигналы (SIGURG/SIGPROF), stack growth — это активная, постоянно мутирующая среда выполнения, и утверждение "работает" на однопоточном getpid()-эксперименте ничего не говорит о том, что произойдёт, если сигнал прилетит ровно в момент, когда горутина сидит внутри голого syscall под Wine — это именно тот открытый вопрос, который наши документы (§3.4, честно) не закрывают, и его действительно стоило бы прогнать эмпирически, а не экстраполировать с простого случая.

[unxed]

Провел аудит и серию стресс-тестов (soak test) под реальным Wine с эмуляцией жесткого переключения потоков, асинхронного вытеснения горутин через SuspendThread/ResumeThread (внутри Wine это SIGUSR1 и usr1_handler) и параллельного блокирующего I/O.

Результаты радуют: сырая инструкция SYSCALL вообще не проходит через user-mode диспетчеры Wine, ядро Linux и Wine's signal_x86_64.c безупречно сохраняют и восстанавливают полный контекст регистров, а системные вызовы после прерывания продолжают работу штатно.

А для нативных C/C++ приложений вроде Far Manager даже рантайм-нюансы Go вообще не актуальны — тут это чистый, предсказуемый переход между стандартами системных вызовов.

[yulian5]

@unxed I tried Far Manager 3 a few years ago under Wine with a few different versions: I was able to make a few simple actions after wasted hours of configurations: then I moved to native Linux file managers.

What is wrong with far2l/far2m? For what reason do you need Far 3 on Linux?

[unxed]

Провёл ещё один аудит. Ничего опасного не нашёл. На всякий случай сделал защиту от "Wine что-то поменяли". Либа на старте делает мгновенный тест реального использования POSIX API таким способом, включая обработку ошибок. И если хоть что-то пошло не так — отключает эту фичу.

unxed/winescape@2869593

What is wrong with far2l/far2m? For what reason do you need Far 3 on Linux?

No need to implement one feature twice, as was with line numbering, for example.

[tempergate]

Обсуждать тут слова друга наверно будет жёстким оффтопиком, но сомнения всё же возникают.

доверять корпоративной нейросети это последнее что нужно делать.

Выше уже сказано про то, что сусколы просто так не меняются.
Дальше если брать платформенные особенности, никто вайнн и не использует нигде кроме x86_64, формально билд под арм существует, но мало кто ей пользуется.

Но в целом, раз такой инструмент есть, то почему бы и нет. Причины могут быть даже в использовании файлменеджера под вайном, есть задачи, когда например в вайне надо чтото запускать в рантайме, и wineexplore на самом деле сильно ограничен функционально

про бзди и альтернативные платформы разговор отдельный, но скорее всего оно будет и там работать, потому что как раз вайн на себя платформенные особенности будет забирать

[yulian5]

@unxed :

No need to implement one feature twice, as was with line numbering, for example.

That's very easy compared to what needed to be implemented in Far 3 to even slightly match far2l/far2m Linux functionality (10 years of work of far2l @elfmz and others).

Here is what one friend told me today:

While running Far Manager 3 in Wine gives you perfect compatibility with old Windows plugins, it fundamentally degrades the Linux experience by filtering everything through Windows APIs. You lose critical native filesystem semantics, meaning no proper handling of Linux file permissions (chmod/chown), symlinks, or special files. Additionally, Far3-in-Wine suffers from poor terminal integration—struggling over SSH or tmux and lacking seamless clipboard support—while missing out on far2l’s entirely Linux-native plugin ecosystem and exclusive features. Ultimately, the loss of native OS integration makes Far 3 on Wine a poor substitute for the natively built far2l/far2m.

Just compare file attributes dialogs in Far 3 and far2l. Or try to run Far 3 in terminal. Or try to use clipboard with Far 3 in Wine.

[unxed]

it fundamentally degrades the Linux experience by filtering everything through Windows APIs

But libwinescape is the thing that SOLVES it! It provies access to POSIX from Wine.

See, it's f4.exe (yet another dual pane fm) in Wine using it. There is no Wine path converters (like from Z:\bin to /bin for example), it's just using system native APIs. And yes, I am planning chmod etc on a top of it. Everything is ready, just dialog have to be a bit adopted.

[yulian5]

Everything is ready, just dialog have to be a bit adopted.

I think it's an illusion. Let's assume your POSIX API is 100% ready. But these POSIX calls should be implemented somehow and it may be dozens of hundreds calls including plugins. Yes, some calls will be auto implemented through Wine. But Windows Far 3 knows nothing about Linux, almost all Linux functionality should be added. And that's a lot, just look into far2l code.

Essentially, you are replacing far2l (WinPort) with Far 3 (Wine+winescape). Given that far2l took 10 years to develop—and considering that the Far 3 codebase is twice the size and complexity of Far 2's—if we factor in that AI can cut this timeframe by a factor of 5 to 10, then we are looking at roughly two-plus years of work to get parity with far2l. And if you want to keep it working on the Windows, add some time for that too.

The f4 project has a better chance of success.

[unxed]

Right, I originally built this library for f4: need it to work perfectly everywhere possible, including Wine. But I propose it for Far 3 as well; of course, we aren't talking about a far2l-level port by tomorrow, but adding simple things like chmod support on POSIX under Wine could be done in 15 minutes now if someone asked.

[yulian5]

OK. Then let me ask again the purpose of your proposal.

far2l with WinPort - native Linux speed, almost everything your need to work in Linux. Yes, old code but very adapted to Linux. Code may be improved to match modern standards (like replacing FARString with C++ standard strings, etc.).

Far 3 + Wine + winescape - slow emulation, basic functions only, hard configuration for every simple action (even with winescape). Adding libwinescape to Wine just adds a small, specific bridge to talk to the host OS. It does nothing to solve the underlying latency created by the Wine translation layer itself. Far 3 has the code very tightly integrated with Windows, much more tightly that Windows Far 2. libwinescape does nothing to add Linux specific functionality to Windows Far 3, everything should be implemented from scratch, you cannot even copy code form far2l, codebase is different.

So what is the purpose, to compete with far2l? Bad idea, emulation will never match the speed of native build. And it requires couple years of hard work just for the acceptable Far 3 Linux functionality.

[unxed]

slow emulation, basic functions only

It seems to me that you may not have had a chance to look closely enough at what winescape actually is and how it works.

Could you please clarify why you expect there to be slow emulation when the most performance-critical operations are passed directly to the POSIX API? In theory, this should actually be faster than far2l, which carries a Win32-to-POSIX translation layer with it.

And why do you say that only basic functionality would be available? Not only disk i/o, but signals, networking, mmap, fs notifications, terminal control are working via winescape right now, and any other APIs can be easily added if needed. I just started with most speed-critical ones so that the user experience doesn't suffer from unnecessary delays or stalls.

I wrote winescape specifically for f4, and I'm extremely demanding when it comes to UX. Slowdowns or "only basic functionality" were simply never acceptable design goals for winescape.

[yulian5]

Ultimately, winescape is a fantastic tool for new projects designed with it in mind.

I agree that passing instructions directly to the POSIX API via libwinescape eliminates Wine's translation overhead for those specific calls. From a purely I/O and kernel perspective, it might actually be faster than far2l's WinPort wrapper.

However, bypassing Wine's documented boundaries remains a clever but fragile hack. Nobody knows how stable this will be for an application as complex as Far 3. The bigger issue is the UX bottleneck. Even with fast disk I/O, Far's UI rendering, clipboard, and keyboard handling are still trapped in Wine's user-mode subsystems. Furthermore, Far 3 plugins won't know how to use winescape, remaining ignorant of Linux semantics. So far it looks like a Frankenstein architecture: fast under the hood, but clunky in the terminal.

Anyway, I genuinely wish you luck with this project.