POV-Ray : Newsgroups : povray.off-topic : An observation Server Time
4 Sep 2024 07:15:48 EDT (-0400)
  An observation (Message 61 to 70 of 107)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Darren New
Subject: Re: An observation
Date: 30 Oct 2010 14:18:46
Message: <4ccc6186$1@news.povray.org>
Jim Henderson wrote:
> Busybox is more to bash than to Ubuntu.  It's a shell, not a kernel.

Sure.  My point being that there's a whole lot more to Linux than the 
kernel, probably little of which is running on Android.

> I'm fairly certain that the Windows kernel code is not platform-
> independent.  Microsoft stopped doing that back when they dropped support 
> for RISC-based Windows to the best of my knowledge.

They stopped *selling* it. I don't know why they'd let it no longer be 
platform independent if they know they want to pursue such things. But since 
neither of us really knows, there's not a whole lot of point in arguing it.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."


Post a reply to this message

From: Jim Henderson
Subject: Re: An observation
Date: 30 Oct 2010 16:08:56
Message: <4ccc7b58$1@news.povray.org>
On Sat, 30 Oct 2010 11:18:46 -0700, Darren New wrote:

> Jim Henderson wrote:
>> Busybox is more to bash than to Ubuntu.  It's a shell, not a kernel.
> 
> Sure.  My point being that there's a whole lot more to Linux than the
> kernel, probably little of which is running on Android.

True, but the analogy doesn't really hold, which was my point.  It was 
like comparing donuts to rollercoasters.  (OK, maybe not *quite* that 
disconnected). :-)

>> I'm fairly certain that the Windows kernel code is not platform-
>> independent.  Microsoft stopped doing that back when they dropped
>> support for RISC-based Windows to the best of my knowledge.
> 
> They stopped *selling* it. I don't know why they'd let it no longer be
> platform independent if they know they want to pursue such things. But
> since neither of us really knows, there's not a whole lot of point in
> arguing it.

True, but I suspect that there's a lot more platform-dependent code in 
Windows than in Linux, based on my own experience.

Jim


Post a reply to this message

From: Patrick Elliott
Subject: Re: An observation
Date: 30 Oct 2010 21:54:01
Message: <4ccccc39$1@news.povray.org>
On 10/29/2010 10:51 AM, Jim Henderson wrote:
> On Fri, 29 Oct 2010 09:49:18 -0700, Darren New wrote:
>
>> Patrick Elliott wrote:
>>> In this specific case, probably true, but then you have "phones" and
>>> other things running this OS too..
>>
>> No you don't.  The OS in the phones is not the normal Windows OS, any
>> more than your Droid phone is running Ubuntu.
>
> However both run a Linux kernel.  I doubt that the Windows kernel is
> what's running on both the Windows platform and Windows Mobile platforms.
>
> Jim
Generally its CE. In other words, a version that has about 90% of the 
crap in Windows PC stripped out, and replaced with a *much* smaller 
subset of drivers and interfaces (which are, never the less, up to a 
point, supporting most of the same API calls).

One of the things left out, at least in earlier versions, since I 
haven't read anything about the newer ones, was the "try/catch" error 
system in the OS. Basically, you either had to code your own variation 
on this, or you have to rely on your code "never" causing an error or 
fault, which might do things it wasn't supposed to. Sort of.. reversion 
to how Win3.11 handled memory allocation and error trapping. lol

So, yeah. Its not exactly the same thing.

Now.. Linux based ones.. As I understand it the kernel may as well be 
the same, assuming the same processor, but the interfaces, i.e. drivers, 
to the rest of the stuff, isn't. If you could build a PC with the same 
processor, then added in the right drivers for the hardware on that 
machine, it would act like any other version of Linux, assuming you 
compiled you code for that machine.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>


Post a reply to this message

From: Darren New
Subject: Re: An observation
Date: 30 Oct 2010 22:08:50
Message: <4ccccfb2$1@news.povray.org>
Jim Henderson wrote:
> True, but I suspect that there's a lot more platform-dependent code in 
> Windows than in Linux, based on my own experience.

Given that Linux *does* run on lots of different CPUs and such, I'd 
certainly believe that. But if MS picks one second platform, I suspect they 
could port significant parts of the kernel and APIs.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."


Post a reply to this message

From: Jim Henderson
Subject: Re: An observation
Date: 30 Oct 2010 23:04:20
Message: <4cccdcb4$1@news.povray.org>
On Sat, 30 Oct 2010 19:08:47 -0700, Darren New wrote:

> Jim Henderson wrote:
>> True, but I suspect that there's a lot more platform-dependent code in
>> Windows than in Linux, based on my own experience.
> 
> Given that Linux *does* run on lots of different CPUs and such, I'd
> certainly believe that. But if MS picks one second platform, I suspect
> they could port significant parts of the kernel and APIs.

Without a doubt.  Windows' roots (starting with NT) was on DEC equipment, 
after all, not x86.

Jim


Post a reply to this message

From: Jim Henderson
Subject: Re: An observation
Date: 30 Oct 2010 23:05:55
Message: <4cccdd13$1@news.povray.org>
On Sat, 30 Oct 2010 18:54:00 -0700, Patrick Elliott wrote:

>  As I understand it the kernel may as well be the
> same, assuming the same processor, but the interfaces, i.e. drivers, to
> the rest of the stuff, isn't.

Um, no, actually, the APIs would be the same because it's the same kernel 
code.

> If you could build a PC with the same processor, then added in the
> right drivers for the hardware on that machine, it would act like any
> other version of Linux, assuming you compiled you code for that machine.

Wait, what?  You seem to be contradicting yourself....

Jim


Post a reply to this message

From: Patrick Elliott
Subject: Re: An observation
Date: 31 Oct 2010 16:29:26
Message: <4ccdd1a6@news.povray.org>
On 10/30/2010 8:05 PM, Jim Henderson wrote:
> On Sat, 30 Oct 2010 18:54:00 -0700, Patrick Elliott wrote:
>
>>   As I understand it the kernel may as well be the
>> same, assuming the same processor, but the interfaces, i.e. drivers, to
>> the rest of the stuff, isn't.
>
> Um, no, actually, the APIs would be the same because it's the same kernel
> code.
>
>> If you could build a PC with the same processor, then added in the
>> right drivers for the hardware on that machine, it would act like any
>> other version of Linux, assuming you compiled you code for that machine.
>
> Wait, what?  You seem to be contradicting yourself....
>
> Jim
How so? Drivers can be compiled into kernel, but most are not any more, 
and they can be added or removed, without effecting the kernel itself. 
You do have to compile it for the specific processor though, so where 
exactly do you think I contradicted myself?

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>


Post a reply to this message

From: Jim Henderson
Subject: Re: An observation
Date: 31 Oct 2010 16:51:29
Message: <4ccdd6d1$1@news.povray.org>
On Sun, 31 Oct 2010 13:29:24 -0700, Patrick Elliott wrote:

> How so? Drivers can be compiled into kernel, but most are not any more,
> and they can be added or removed, without effecting the kernel itself.
> You do have to compile it for the specific processor though, so where
> exactly do you think I contradicted myself?

Looking at the source for the version of Android on my phone, I see the 
drivers in with the kernel source.

My router (which is not Android-based, but Linux based) is the same.  Not 
x86 hardware, but it uses drivers for hardware that is readily available 
on x86 systems, so the drivers are in the kernel tree.

Jim


Post a reply to this message

From: Jim Henderson
Subject: Re: An observation
Date: 31 Oct 2010 16:52:37
Message: <4ccdd715$1@news.povray.org>
On Sun, 31 Oct 2010 16:51:29 -0400, Jim Henderson wrote:

> On Sun, 31 Oct 2010 13:29:24 -0700, Patrick Elliott wrote:
> 
>> How so? Drivers can be compiled into kernel, but most are not any more,
>> and they can be added or removed, without effecting the kernel itself.
>> You do have to compile it for the specific processor though, so where
>> exactly do you think I contradicted myself?
> 
> Looking at the source for the version of Android on my phone, I see the
> drivers in with the kernel source.
> 
> My router (which is not Android-based, but Linux based) is the same. 
> Not x86 hardware, but it uses drivers for hardware that is readily
> available on x86 systems, so the drivers are in the kernel tree.

Note that when I do compiles for my router, the drivers are modules, but 
they're still part of the kernel source tree.  Modular or compiled-in 
modules still tend to be in the kernel source tree unless you're talking 
about something like the proprietary NVidia or ATI drivers.

Jim


Post a reply to this message

From: Darren New
Subject: Re: An observation
Date: 31 Oct 2010 17:14:01
Message: <4ccddc19$1@news.povray.org>
Jim Henderson wrote:
> Without a doubt.  Windows' roots (starting with NT) was on DEC equipment, 
> after all, not x86.

Heh.  I don't think they took actual VMS code and tried to port it for Windows.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.