new linux standard

[kerravon]

So based on another post, I want to be able to write Linux apps such that they run under both PDOS-generic and real Linux.

Linux is set in stone, but PDOS-generic isn't. And also I have no problem invalidating all existing Linux apps, including my own. I never agreed on a standard, and if some professor or the POSIX committee or Thomo/Lillee/Richie Rich didn't allow for this 50 years ago or whatever - that's not my fault.

So I'll start with x64, since it is the most complicated. And this is just tentative first thoughts.

PDOS-generic may be running in userspace on Windows x64 with no access to interrupts, so I can't intercept the "syscall" instruction (whatever that is). I instead need all Properly Written (TM) Linux apps to gracefully accept a linux_syscall() callback override which would be part of the PDOS-generic OS structure.

But the app needs to know whether it is running under PDOS-generic or real Linux. And it can't e.g. look at an environment variable by doing a syscall, because syscall may not be allowed - that's the whole point.

So PDOS-generic can call the Linux app (entry point funcptr) with:

funcptr( (void *)(ptrdiff_t)-1, (void *)(ptrdiff_t)-2, (void *)(ptrdiff_t)-3, &OS_BLOCK);

The startup assembler code for the Linux app will push the following registers onto the stack:

rcx, rdx, r8, r9, (these first 4 are MSABI) rdi, rsi

rdi, rsi, rdx, rcx, r8, r9 is Linux calling convention for parameters.

I may wish to use either of those calling conventions depending on what compiler I have available.

I then pass a pointer to the stack to the C startup code, so it can figure out the environment in C instead of assembler.

On real Linux x64, I don't think any of those registers are guaranteed to be anything, so that could be a problem.

But otherwise, I can look for the -1, -2, -3 sequence in either rcx/rdx/r8 or rdi/rsi/rdx so I know that the caller is PDOS-generic and I know where to find the OS pointer and I can do my callbacks instead of real syscalls. If that sequence is not detected, I know it is real Linux and carry on as usual doing syscall, and also I know the location of argc/argv if I am forced to get that from the stack instead of /proc/.../cmdline (I use this so that PDOS/386 has a chance to provide parameters to a Linux app without creating a stupid stack - PDOS/386 handles a real INT 80H).


For 80386, PDOS-generic is still going to do the same call, but now everything is on the stack instead of in registers.

I again have assembler startup code to push the current stack pointer onto the stack as the parameter to the C startup code.

If this is PDOS-generic, the stack will have a return address followed by -1, -2, -3, OS. The OS will have an int80() callback function to override the real INT 80H. ie all Properly Written (TM) Linux apps are expected to call the callback function if the OS (no matter who - maybe real Linux will be updated one day for whatever reason someone has to not want a real interrupt done) tells it (via this mechanism) to do a callback, not a real interrupt.

If this is Linux I will have argc immediately, and I will not be able to differentiate that from a return address.

Real Linux will then have argc, and the value of -2 will not be (reasonably) valid. Possibly I could have an additional -1 parameter to be sure, so perhaps a sequence of -1, -1, -2, OS. Another possibility is to have three -1 to make sure argv[0] is an invalid pointer. Either -1, -1, -1, OS or -1, -1, -1, -2, OS. That last one will cause x64 to spill from registers into the stack, but that can be coped with, and may even be a good thing. Perhaps even having 8 or more parameters would be good for x64 detection purposes.

Whatever the number and value of parameters are, I expect it to be consistent regardless of ARM32/64 x86/x64, so that the PDOS-generic OS can be portable for the PDOS-generic app point of view. If it is acting as a mini Linux clone or mini Atari clone, I can have extra/different callback functions made available, but the PDOS-generic apps remain the same (ie with a view to setting the PDOS-generic API in stone too - PDOS-generic apps need to know to ignore the first x parameters and just get the parameter with the OS structure which contains everything they need).

Just initial thoughts.

[iansjack]

So based on another post, I want to be able to write Linux apps such that they run under both PDOS-generic and real Linux.

I’m afraid that my reaction is - why?

Why add extra layers, inefficiencies, and complications when you can just recompile programs for the target OS?

“The good thing about standards is that there are so many to choose from.”

[kerravon]

So based on another post, I want to be able to write Linux apps such that they run under both PDOS-generic and real Linux.

I’m afraid that my reaction is - why?

Why add extra layers, inefficiencies, and complications when you can just recompile programs for the target OS?

So that I can have a binary that works on both Linux and Linux-clone, instead of needing to find the source code and build a PDOS-generic executable.

It's not unusual to want binary compatibility.

[iansjack]

You are writing the programs and you need to search for the source code?

It’s not unusual to want binary compatibility

I’d disagree with your premise. IMO users want a program that will run on Windows, Linux, Mac OS, FreeBSD, etc., but very few have a desire for a single binary that will run on all four. Personally I prefer binaries that have benn compiled for, and take advantage of the efficiencies that entails, a single operating system.

[kerravon]

You are writing the programs and you need to search for the source code?

It's not necessarily me doing it. If someone has compiled a set of Linux executables, then yes, they will need to recompile for another environment.

It’s not unusual to want binary compatibility

I’d disagree with your premise. IMO users want a program that will run on Windows, Linux, Mac OS, FreeBSD, etc., but very few have a desire for a single binary that will run on all four. Personally I prefer binaries that have benn compiled for, and take advantage of the efficiencies that entails, a single operating system.

The program nominally only runs on Linux.

Or a clone of Linux.

I am providing a clone of Linux, similar to how Wine provides a clone of Windows.

For my clone to work, I need a slight change to the Linux standard.

I don't know (or care) if Wine requires privilege. My (proposed) Linux clone doesn't need privilege because it avoids having to do an INT 80H etc. The same way as my Atari mini-clone avoids a 68000 trap. By first changing the Atari standard.

[Octocontrabass]

I am providing a clone of Linux, similar to how Wine provides a clone of Windows.

The entire point of Wine is that it runs existing Windows binaries. If you needed special "Wine-compatible" binaries to use Wine, nobody would use Wine.

What you're suggesting is the equivalent of Wine requiring special "Wine-compatible" binaries.

[kerravon]

I am providing a clone of Linux, similar to how Wine provides a clone of Windows.

The entire point of Wine is that it runs existing Windows binaries. If you needed special "Wine-compatible" binaries to use Wine, nobody would use Wine.

I would. I would be happy to modify the way I build Windows executables so that Wine can handle them. E.g. not using undocumented APIs which is the main reason Wine won't handle existing binaries (I believe). So long as it is a minor change, and Wine doesn't expect a complete rebuild of my Windows apps to include an effective second copy of the application that uses Linux calls. I don't want to do Linux calls, I want to do Windows calls.

I guess that's the key difference. I'm interested in clones. I'm interested in "common subsets" of clones. I'm willing to build my executables so that they run on multiple Windows clones - be it real Windows, Linspire, ReactOS, PDOS/386, Wine, MSDOS 4.0+HX.

I may decide that a particular clone is just too bad - e.g. maybe ReactOS is just too bad - so I abandon that clone. But so long as it is "reasonable", I'm happy to take care when building my binaries to cover as many clones as possible. Ideally this should have been sorted out in 1993 - or even earlier - Win32 could have been made available on the Amiga in 1985 - but I'm not worried about being "late to the party".

Again - this is my goal, not someone else's goal. My expectations of Wine. I'm happy to listen to the manufacturers of Wine if they need assistance. If others demand 100% MS compatibility - take it or leave it - so be it - that's someone else's goal, not mine.

What you're suggesting is the equivalent of Wine requiring special "Wine-compatible" binaries.

Yes indeed. And I don't have a problem with that - or at least, I'm happy to ask the question - "what do you need, Mr Wine?". If they ask for too much, forget it. It so happens that the Wine people asked for nothing more than to use documented APIs - I can do that. If they ask for a little bit more - tell me what it is exactly and then I'll decide.


EDIT: thanks for teasing out that "unstated assumption". I don't know what unstated assumptions I am running on until I see a disconnect during a discussion.