On 12/30/2023 9:01 PM, Physfitfreak wrote:
On 12/30/2023 8:54 PM, Physfitfreak wrote:
When one goes from a computer to another computer with a different
CPU, and installs the same copy of OS on the new computer, how does
the OS know how to use a different CPU?
I guess I could ask the same question in this way as well:
Are there "drivers" for each CPU made, which the OS automatically
searches and finds and uses so it can run on different CPU machines? I
can't think of any other way for the same copy of OS working on
different CPU machines.
And if that's the case (drivers available for each particular CPU) then
how the machine works with other OS's installed on it? Are there drivers
for each OS in the market also available for that particular CPU? That
makes (number of CPUs) X (number of OS's) drivers! Is this the correct situation?
When one goes from a computer to another computer with a different CPU,
and installs the same copy of OS on the new computer, how does the OS
know how to use a different CPU?
On 12/30/2023 9:01 PM, Physfitfreak wrote:
On 12/30/2023 8:54 PM, Physfitfreak wrote:
When one goes from a computer to another computer with a different
CPU, and installs the same copy of OS on the new computer, how does
the OS know how to use a different CPU?
I guess I could ask the same question in this way as well:
Are there "drivers" for each CPU made, which the OS automatically
searches and finds and uses so it can run on different CPU machines? I
can't think of any other way for the same copy of OS working on
different CPU machines.
And if that's the case (drivers available for each particular CPU) then
how the machine works with other OS's installed on it? Are there drivers
for each OS in the market also available for that particular CPU? That
makes (number of CPUs) X (number of OS's) drivers! Is this the correct situation?
When one goes from a computer to another computer with a different CPU,
and installs the same copy of OS on the new computer, how does the OS
know how to use a different CPU?
If a C++ program's EXE file can only run on same machine with same
Windows version, then it is as good as crap. Cause you'd have to use its
cpp source code and _recompile_ and relink on another machine or another version of windows. The EXE form of the program gets ridiculously
limited, and will have to get recreated over and over to make it run on
a new computer or new version of Windows.
That's the whole point of compiling.
This is ridiculous
As I said in another post today, things don't have to be the way there
are right now. A more logical way to adopt is to create a standard for
CPU's by which they would create the exact same result for each
particular machine language command, regardless of what CPU it is that
the machine language instruction is applied to.
Then, any EXE file in the world would run on any CPU following that
standard. Why hasn't this been done?
On 1/1/2024 9:03 AM, Farley Flud wrote:
On Sun, 31 Dec 2023 16:32:45 -0600, Physfitfreak wrote:
If a C++ program's EXE file can only run on same machine with same
Windows version, then it is as good as crap. Cause you'd have to use its >>> cpp source code and _recompile_ and relink on another machine or another >>> version of windows. The EXE form of the program gets ridiculously
limited, and will have to get recreated over and over to make it run on
a new computer or new version of Windows.
That's the whole point of compiling.
Compilation is the translation of source code into machine language
instructions for a specific CPU. If the CPUs are not the same, then
the source must be compiled again for the different CPU.
There is no way to avoid this. That's why they have distros because
it removes the burden of compiling from the user.
Even on the same machine (CPU), if a program (exe) depends on a library
and that library is updated then the program needs to be compiled again.
On my Gentoo system, for example, there are times when a single library
is updated and that will mandate the re-compiling of many other programs.
That's computer reality. It's compile, compile, and compile again all
the time. There is no other way.
Again, most users don't notice because they use distros and a distro
does all the work for them. But a distro is ALWAYS sub-optimal in terms
of performance.
But your question also concerns "cross compiling:"
https://en.wikipedia.org/wiki/Cross_compiler
Cross compiling is compiling source code on one machine (CPU) so
that it will execute on a different machine with a different CPU.
Then why, after all these years, this job is still being relegated to
the user or certain distros? Why haven't they come up with a standard at
the machine language level, so _any_ EXE file could flawlessly run on
_any_ CPU following that standard?... This is ridiculous. I don't think
it is impossible to create a standard by which machine language
instructions themselves, each, creating identical results from it,
regardless of what CPU it is as long as CPUs themselves are following
certain standards.
The way it is now, is like some schmuck in Intel suddenly gets erection
to create a CPU that follows his own dick and nothing else, thus
throwing all the time and efforts made to get work done in the world on
a previous type of CPU in the waste basket, and make all developers
start from the beginning creating new OS, new programs , new everything
just so they would work on the dick-aligned schmuck's CPU.
This is ridiculous...
A standard at the machine language level will put all the CPUs in the
world plus all of those who'll come in the future, inside a Black Box,
if they follow that standard! Then it wouldn't matter what pc or what os
or what mainframe it is that your EXE file that's compiled only once in
its lifetime, wants to run on. Doesn't it make sense?
I don't imagine a reason to make a universal machine language.
candycanearter07 wrote:
Also the lack of compatibility also comes from relying on Windows DLL
files (compiled libraries, equivelant of Linux .so files) that provide
core functionality and are missing on Linux systems. And, even if you do
download them with WiNE, it still needs to be translating it to Linux
syscalls because none of the source code for it is open.
Sure, and that's why the compatibility cannot come via something done
higher up. You'd have to go down to machine level instructions and make >_that_ compatible to all machines. An EXE file has everything it needs >already built into it.
candycanearter07 <no@thanks.net> wrote:
On 1/1/24 17:31, Physfitfreak wrote:
A standard at the machine language level will put all the CPUs in the
world plus all of those who'll come in the future, inside a Black Box,
if they follow that standard! Then it wouldn't matter what pc or what os >>> or what mainframe it is that your EXE file that's compiled only once in
its lifetime, wants to run on. Doesn't it make sense?
From what I understand, most CPU standards are legacy from what they
made in the past, so it would be near-impossible to get everyone to
agree on something.
I don't imagine a reason to make a universal machine language.
Also the lack of compatibility also comes from relying on Windows DLL
files (compiled libraries, equivelant of Linux .so files) that provide
core functionality and are missing on Linux systems. And, even if you do
download them with WiNE, it still needs to be translating it to Linux
syscalls because none of the source code for it is open.
Wine is a remarkable system, I am using it literally as I type this,
to run a Winblows NNTP client. Can't beat Linux to me.
Then why, after all these years, this job is still being relegated to
the user or certain distros? Why haven't they come up with a standard at
the machine language level, so _any_ EXE file could flawlessly run on
_any_ CPU following that standard?...
This is ridiculous.
I don't think
it is impossible to create a standard by which machine language
instructions themselves, each, creating identical results from it,
regardless of what CPU it is as long as CPUs themselves are following
certain standards.
A standard at the machine language level will put all the CPUs in the
world plus all of those who'll come in the future, inside a Black Box,
if they follow that standard!
Doesn't it make sense?
I don't imagine a reason to make a universal machine language.
An EXE file has everything it needs already built into it.
Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
I don't imagine a reason to make a universal machine language.
Because a programmer want to program and to spend his time to improve
his program. He doesn't want to spend most of his time to adapt it to
every user he has. So if there is only one binary to give, it's easy.
And that's why java was invented.
Then create a CPU based on Java.
But until then, there are lower
level instructions that for a human are assembly language, which can
be derived with a C compiler's output, in machine language readable
into address space for the process.
Java is too fucking slow.
candycanearter07 <no@thanks.net> wrote:
Wine is a remarkable system, I am using it literally as I type this,
to run a Winblows NNTP client. Can't beat Linux to me.
Yes, but it still does need to do some translation, which causes
overhead. And, not everything (cough Adobe) is compatible with it yet.
I had Photoshop, when I deleted Win11. I wasn't going to renew the subscription this year, anyway. I was interested in using it, sure,
but only because it exists, I never figured out how to do anything
that great with it. GIMP, now, is just what is on Linux and really
what one needs. Just as Wine provides the means to run a couple of
Winblows apps, then you have the usual variety of apps one uses a lot.
I believe using Wine is easily worth it, compared to merely running
Windows 10 or 11 in their current builds.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 07:43:12 |
| Calls: | 6,706 |
| Files: | 12,236 |
| Messages: | 5,350,636 |