Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:

> When professional programmers get PAID for their labours, they put out
> KUALITY KODE. The same cannot be said for the part-time, unpaid, hippy
> amateur Linux coders.

If that is true, then explain this.

1. Windows 3.0 was a graphical shell built around a 16-bit kernel which
was unable to address more than 640Kb of RAM without external programs to
support that addressing. Windows Vista is a graphical shell built around
a 32- bit or 64-bit kernel which *is* unable to address more than 640Kb
of RAM without external programs to support that addressing. Linux
version 2.6 (the kernel, NOT any particular distro) addresses up to a gig
or more of RAM natively.How is Windows better.

2. Most, if not all of the windows networking stack was and to this day
still is an after-thought (see windows 3.11 for workgroups for
explanation) which only partly works, based on the networking systems
built in to the linux/unix kernel at the time. How, then, is Windows
better.

"Mark Trimble" wrote in message
newsan.2007.10.22.22.41.33@127.0.0.1...
> Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:
>
>> When professional programmers get PAID for their labours, they put out
>> KUALITY KODE. The same cannot be said for the part-time, unpaid, hippy
>> amateur Linux coders.
>
> If that is true, then explain this.
>
> 1. Windows 3.0 was a graphical shell built around a 16-bit kernel which
> was unable to address more than 640Kb of RAM without external programs to
> support that addressing.

True. This was to maintain compatibility with older DOS applications that
relied on this behavior.


> Windows Vista is a graphical shell built around
> a 32- bit or 64-bit kernel which *is* unable to address more than 640Kb
> of RAM without external programs to support that addressing.

This is complete and utter bull****.


> Linux
> version 2.6 (the kernel, NOT any particular distro) addresses up to a gig
> or more of RAM natively.How is Windows better.

When it comes to address memory there is no significant difference between
XP/Vista or linux. Your claim of XP/Vista not being able to address more
than 640k is complete bull****.


> 2. Most, if not all of the windows networking stack was and to this day
> still is an after-thought (see windows 3.11 for workgroups for
> explanation) which only partly works, based on the networking systems
> built in to the linux/unix kernel at the time. How, then, is Windows
> better.

More bull****. The networking model in in the NT family of products (NT,
Win2k, XP, Vista, etc) is not based at all on the Windows for Workgroups
model.

Once again you prove to be inadequately informed.



--
Posted via a free Usenet account from http://www.teranews.com

Micoshaft Asstroturfer Simon Templar wrote on behalf of Micoshaft
Corporation:

>
> "Mark Trimble" wrote in message
> newsan.2007.10.22.22.41.33@127.0.0.1...
>> Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:
>>
>>> When professional programmers get PAID for their labours, they put out
>>> KUALITY KODE. The same cannot be said for the part-time, unpaid, hippy
>>> amateur Linux coders.
>>
>> If that is true, then explain this.
>>
>> 1. Windows 3.0 was a graphical shell built around a 16-bit kernel which
>> was unable to address more than 640Kb of RAM without external programs to
>> support that addressing.
>
> True. This was to maintain compatibility with older DOS applications that
> relied on this behavior.
>
>
>> Windows Vista is a graphical shell built around
>> a 32- bit or 64-bit kernel which *is* unable to address more than 640Kb
>> of RAM without external programs to support that addressing.
>
> This is complete and utter bull****.
>
>
>> Linux
>> version 2.6 (the kernel, NOT any particular distro) addresses up to a gig
>> or more of RAM natively.How is Windows better.
>
> When it comes to address memory there is no significant difference between
> XP/Vista or linux. Your claim of XP/Vista not being able to address more
> than 640k is complete bull****.


You are a complete fool expounding utter bullcrap.
The difference you are being asked to explain is difference between native
support and support through slower helper programs. Expee, Pista don't do
native addressing, so it must rely on slower helper programs and is
therefore slow; unlike Linux which accesses RAM directly.

I'm not expert on this particular question, but it still doesn't excuse you
from printing appauling escapism.

In comp.os.linux.advocacy, 7

wrote
on Tue, 23 Oct 2007 00:20:35 GMT
:
> Micoshaft Asstroturfer Simon Templar wrote on behalf of Micoshaft
> Corporation:
>
>>
>> "Mark Trimble" wrote in message
>> newsan.2007.10.22.22.41.33@127.0.0.1...
>>> Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:
>>>
>>>> When professional programmers get PAID for their labours, they put out
>>>> KUALITY KODE. The same cannot be said for the part-time, unpaid, hippy
>>>> amateur Linux coders.
>>>
>>> If that is true, then explain this.
>>>
>>> 1. Windows 3.0 was a graphical shell built around a 16-bit kernel which
>>> was unable to address more than 640Kb of RAM without external programs to
>>> support that addressing.
>>
>> True. This was to maintain compatibility with older DOS applications that
>> relied on this behavior.
>>
>>
>>> Windows Vista is a graphical shell built around
>>> a 32- bit or 64-bit kernel which *is* unable to address more than 640Kb
>>> of RAM without external programs to support that addressing.
>>
>> This is complete and utter bull****.

I'm inclined to agree, if only because the Winvista shell
is presumably a user-level application program that uses
the Windows APIs and runs in Windows' "innovative" flat
address space -- a space that existed for Unix and other
systems quite some time ago (probably even as early as
the late 1970's, when Vaxes first came out!).

It's only the Win3.1 and Win9x era tools that had to worry
about FAR PTR crap. (Thank goodness.)

>>
>>
>>> Linux
>>> version 2.6 (the kernel, NOT any particular distro) addresses up to a gig
>>> or more of RAM natively.How is Windows better.
>>
>> When it comes to address memory there is no significant difference between
>> XP/Vista or linux. Your claim of XP/Vista not being able to address more
>> than 640k is complete bull****.
>
>
> You are a complete fool expounding utter bullcrap.
> The difference you are being asked to explain is difference between native
> support and support through slower helper programs. Expee, Pista don't do
> native addressing, so it must rely on slower helper programs and is
> therefore slow; unlike Linux which accesses RAM directly.

Pedant Point: Neither Linux nor Vista access RAM directly.
Both go through the processor's MMU (first appearing
sometime in the 286 era -- which predated Linux and
Win3.1). Linux has the slight advantage of intelligent
page management; Win 3.1 had to use the E800: hack.
I would hope Win95 knew how to intelligently manage page
tables, but I for one have my doubts. I know nothing
about NT's handling of such issues but the entire PC
architecture and its "conventional" memory hack is a
necessary stupidity based on upward compatibility, and
should ideally have been shot on sight but was probably
a godsend when it first appeared.

A quick Google coughed up

http://www.ercb.com/feature/feature.0029.html

which suggests a rather complicated but reasonably
conventional internal structure, consisting of a paged
pool and two nonpaged pools (general use and emergency
zippy backup).

The official crap was also coughed up:

http://msdn2.microsoft.com/en-us/library/ms810616.aspx

suggesting a 2G/2G address space and a 10-10-12 split
within an address -- which is a slight inconsistency as
there probably should be a 1-9-10-12 split instead (the
first bit indicating which of the 2 GB realms to use).
The docs refer to a "btree" structure (not quite correct;
it's more of a fixed-height fixed-N-way tree system). Most
of this appears dictated by the x86's peculiarities, what
little I know about such.

Apart from a specialized "bad" page marker, this looks
reasonably conventional. Presumably Vista has not made
too many changes in this area, though I'm wondering how
64 GB is handled.

>
> I'm not expert on this particular question, but it still doesn't
> excuse you from printing appauling escapism.
>

--
#191, ewill3@earthlink.net
Windows. When it absolutely, positively, has to crash.

--
Posted via a free Usenet account from http://www.teranews.com

On 2007-10-22 17:53:45 -0400, raylopez99 said:

> When professional programmers get PAID for their labours, they put out
> KUALITY KODE. The same cannot be said for the part-time, unpaid,
> hippy amateur Linux coders.



LOL! Vista= "Look at my tumor, isn't it CUTE????

Vista=SUCKS ****.

On Mon, 22 Oct 2007 14:53:45 -0700, raylopez99 wrote:

> When professional programmers get PAID for their labours, they put out
> KUALITY KODE. The same cannot be said for the part-time, unpaid, hippy
> amateur Linux coders.
>
> RL
>
> http://windowsvistablog.com/blogs/wi...windows-vista-
service-pack-1-beta-whitepaper.aspx
>
> When developing Windows Vista, Microsoft set out to provide higher
> levels of productivity, mobility, and security, with lower costs. After
> more than six months of broad availability and usage, it's evident that
> these investments are improving the Windows computing experience. For
> example, in the first six months of use, Windows Vista had fewer
> security issues than Windows XP (Windows Vista had only 12 issues, and
> Windows XP had 36). According to the Windows Vista 6-Month Vulnerability
> Report by Jeffery R. Jones, Windows Vista had fewer security issues than
> all the popular operating systems he studied.
>
> Microsoft's efforts to provide the best Windows experience ever in
> Windows Vista did not end with its launch. This white paper describes
> the ways Microsoft strives to continuously improve Windows Vista. It
> then introduces Windows Vista Service Pack 1 (SP1) and describes how the
> service pack will fit into the ongoing improvement process.

This has to be satire. There are a lot of words that can be used to
describe Vista, but quality isn't one of the,.

In comp.os.linux.advocacy, Larry's prostate

wrote
on Mon, 22 Oct 2007 21:23:47 -0400
<471d4d19$0$32506$4c368faf@roadrunner.com>:
> On 2007-10-22 17:53:45 -0400, raylopez99 said:
>
>> When professional programmers get PAID for their labours, they put out
>> KUALITY KODE. The same cannot be said for the part-time, unpaid,
>> hippy amateur Linux coders.
>
>
>
> LOL! Vista= "Look at my tumor, isn't it CUTE????
>
> Vista=SUCKS ****.
>

Vista is also the default offered solution for most new
desktop-based machinery.

The good news: Dell's in trouble (not sure how serious),
and is casting about for new markets. Linux server sales
are up compared, presumably, to Windows server sales.

http://blogs.techrepublic.com.com/tech-news/?p=1386

The bad news (AFAIK): Microsoft wins in most perception
contests, at the desktop level. After all, they're the
devil we know.

--
#191, ewill3@earthlink.net
"Your mother was a hamster and your father smelt of
elderberries!" - Monty Python and the Holy Grail

--
Posted via a free Usenet account from http://www.teranews.com

Quoting Simon Templar on Mon, 22 Oct 2007 19:36:28 -0400:

> "Mark Trimble" wrote in message
> newsan.2007.10.22.22.41.33@127.0.0.1...
>> Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:
>>
>>> When professional programmers get PAID for their labours, they put out
>>> KUALITY KODE. The same cannot be said for the part-time, unpaid,
>>> hippy amateur Linux coders.
>>
>> If that is true, then explain this.
>>
>> 1. Windows 3.0 was a graphical shell built around a 16-bit kernel which
>> was unable to address more than 640Kb of RAM without external programs
>> to support that addressing.
>
> True. This was to maintain compatibility with older DOS applications
> that relied on this behavior.
>
>
>> Windows Vista is a graphical shell built around a 32- bit or 64-bit
>> kernel which *is* unable to address more than 640Kb of RAM without
>> external programs to support that addressing.
>
> This is complete and utter bull****.
>
>
>> Linux
>> version 2.6 (the kernel, NOT any particular distro) addresses up to a
>> gig or more of RAM natively.How is Windows better.
>
> When it comes to address memory there is no significant difference
> between XP/Vista or linux. Your claim of XP/Vista not being able to
> address more than 640k is complete bull****.
>
>
>> 2. Most, if not all of the windows networking stack was and to this day
>> still is an after-thought (see windows 3.11 for workgroups for
>> explanation) which only partly works, based on the networking systems
>> built in to the linux/unix kernel at the time. How, then, is Windows
>> better.
>
> More bull****. The networking model in in the NT family of products (NT,
> Win2k, XP, Vista, etc) is not based at all on the Windows for Workgroups
> model.
>
> Once again you prove to be inadequately informed.
>
>

Then why, pray tell, does Vista still have a pair of files known as
command.com and io.exe in the root level of the boot partition?

Why, pray tell, does vista not interoperate natively?

Mark Trimble pisze:

>
> Then why, pray tell, does Vista still have a pair of files known as
> command.com and io.exe in the root level of the boot partition?
>
> Why, pray tell, does vista not interoperate natively?

Strange, my Vista boot without those files :P Seems that you have
special version :P

--
| Andrea | http://czerwona-linia.blogspot.com/ |
------------------------------------------------
There is no such thing as overkill, there is
only "where's the ammunition" question.

On Mon, 22 Oct 2007 22:41:34 GMT, Mark Trimble wrote:

> 1. Windows 3.0 was a graphical shell built around a 16-bit kernel which
> was unable to address more than 640Kb of RAM without external programs to
> support that addressing.

Actually, that was a DOS limitation and since Windows 3.0 "enhanced
mode" appeared much of the required functionality was built in to the
Windows graphical shell. As Windows progressed through the Windows
95-98-ME line, more and more of this functionality was incorporated.


> Windows Vista is a graphical shell built around a 32- bit or 64-bit
> kernel which *is* unable to address more than 640Kb of RAM without
> external programs to support that addressing.

This is completely and utterly false. The Vista kernel is based on the
NT one, which certainly can address more than 640 KB of memory.


> 2. Most, if not all of the windows networking stack was and to this
> day still is an after-thought (see windows 3.11 for workgroups for
> explanation) ...

This is completely false for versions of Windows based on the NT kernel
(NT, XP, Vista), and at least arguably false for the Windows 95-ME line.

Please don't advocate Linux by making up lies about the competition.


--
-| Bob Hauck
-| "Reality has a well-known liberal bias." -- Stephen Colbert
-| http://www.haucks.org/

"Mark Trimble" wrote in message
newsan.2007.10.23.03.08.52@127.0.0.1...
> Quoting Simon Templar on Mon, 22 Oct 2007 19:36:28 -0400:
>
>> "Mark Trimble" wrote in message
>> newsan.2007.10.22.22.41.33@127.0.0.1...
>>> Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:
>>>
>>>> When professional programmers get PAID for their labours, they put out
>>>> KUALITY KODE. The same cannot be said for the part-time, unpaid,
>>>> hippy amateur Linux coders.
>>>
>>> If that is true, then explain this.
>>>
>>> 1. Windows 3.0 was a graphical shell built around a 16-bit kernel which
>>> was unable to address more than 640Kb of RAM without external programs
>>> to support that addressing.
>>
>> True. This was to maintain compatibility with older DOS applications
>> that relied on this behavior.
>>
>>
>>> Windows Vista is a graphical shell built around a 32- bit or 64-bit
>>> kernel which *is* unable to address more than 640Kb of RAM without
>>> external programs to support that addressing.
>>
>> This is complete and utter bull****.
>>
>>
>>> Linux
>>> version 2.6 (the kernel, NOT any particular distro) addresses up to a
>>> gig or more of RAM natively.How is Windows better.
>>
>> When it comes to address memory there is no significant difference
>> between XP/Vista or linux. Your claim of XP/Vista not being able to
>> address more than 640k is complete bull****.
>>
>>
>>> 2. Most, if not all of the windows networking stack was and to this day
>>> still is an after-thought (see windows 3.11 for workgroups for
>>> explanation) which only partly works, based on the networking systems
>>> built in to the linux/unix kernel at the time. How, then, is Windows
>>> better.
>>
>> More bull****. The networking model in in the NT family of products (NT,
>> Win2k, XP, Vista, etc) is not based at all on the Windows for Workgroups
>> model.
>>
>> Once again you prove to be inadequately informed.
>>
>>
>
> Then why, pray tell, does Vista still have a pair of files known as
> command.com and io.exe in the root level of the boot partition?

I don't know and don't really care. Command.com is the old 16-bit command
shell. It was kept around for a while for old apps (Lotus 123, Wordperfect,
etc) that needed it. Surely you're not stupid enough to think that the
ancient 16-bit command.com is used to manage memory for Vista?

If your claim is that Vista or XP is somehow based on some ancient 640k
memory limit then let's see some proof. You are totally clueless so let's
see some technical article (not a blog entry from someone equally clueless)
that explains this in detail. Until then you are simply spewing bull****.


> Why, pray tell, does vista not interoperate natively?

Enough with your stupid "pray tell" - And what in the world does not
interoperate natively mean?





--
Posted via a free Usenet account from http://www.teranews.com

Quoting Andrea on Tue, 23 Oct 2007 14:14:37 +0200:

> Mark Trimble pisze:
>
>
>> Then why, pray tell, does Vista still have a pair of files known as
>> command.com and io.exe in the root level of the boot partition?
>>
>> Why, pray tell, does vista not interoperate natively?
>
> Strange, my Vista boot without those files :P Seems that you have
> special version :P
>

Not my version - I post from Mandriva 2007.0. I found those files on a
demo model at a big-box computer store near my home town.

Quoting Simon Templar on Tue, 23 Oct 2007 10:46:08 -0400:

> "Mark Trimble" wrote in message
> newsan.2007.10.23.03.08.52@127.0.0.1...
>> Quoting Simon Templar on Mon, 22 Oct 2007 19:36:28 -0400:
>>
>>> "Mark Trimble" wrote in message
>>> newsan.2007.10.22.22.41.33@127.0.0.1...
>>>> Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:
>>>>
>>>>> When professional programmers get PAID for their labours, they put
>>>>> out KUALITY KODE. The same cannot be said for the part-time,
>>>>> unpaid, hippy amateur Linux coders.
>>>>
>>>> If that is true, then explain this.
>>>>
>>>> 1. Windows 3.0 was a graphical shell built around a 16-bit kernel
>>>> which was unable to address more than 640Kb of RAM without external
>>>> programs to support that addressing.
>>>
>>> True. This was to maintain compatibility with older DOS applications
>>> that relied on this behavior.
>>>
>>>
>>>> Windows Vista is a graphical shell built around a 32- bit or 64-bit
>>>> kernel which *is* unable to address more than 640Kb of RAM without
>>>> external programs to support that addressing.
>>>
>>> This is complete and utter bull****.
>>>
>>>
>>>> Linux
>>>> version 2.6 (the kernel, NOT any particular distro) addresses up to a
>>>> gig or more of RAM natively.How is Windows better.
>>>
>>> When it comes to address memory there is no significant difference
>>> between XP/Vista or linux. Your claim of XP/Vista not being able to
>>> address more than 640k is complete bull****.
>>>
>>>
>>>> 2. Most, if not all of the windows networking stack was and to this
>>>> day still is an after-thought (see windows 3.11 for workgroups for
>>>> explanation) which only partly works, based on the networking systems
>>>> built in to the linux/unix kernel at the time. How, then, is Windows
>>>> better.
>>>
>>> More bull****. The networking model in in the NT family of products
>>> (NT, Win2k, XP, Vista, etc) is not based at all on the Windows for
>>> Workgroups model.
>>>
>>> Once again you prove to be inadequately informed.
>>>
>>>
>>>
>> Then why, pray tell, does Vista still have a pair of files known as
>> command.com and io.exe in the root level of the boot partition?
>
> I don't know and don't really care. Command.com is the old 16-bit
> command shell. It was kept around for a while for old apps (Lotus 123,
> Wordperfect, etc) that needed it. Surely you're not stupid enough to
> think that the ancient 16-bit command.com is used to manage memory for
> Vista?
>
> If your claim is that Vista or XP is somehow based on some ancient 640k
> memory limit then let's see some proof. You are totally clueless so
> let's see some technical article (not a blog entry from someone equally
> clueless) that explains this in detail. Until then you are simply
> spewing bull****.
>
>
>> Why, pray tell, does vista not interoperate natively?
>
> Enough with your stupid "pray tell" - And what in the world does not
> interoperate natively mean?
>
>
>
>
>

Getting a little defensive are we?

I've been studying the design and construction of Windows as it affects
my activities as a computer hobbyist for about the last 15 years, and
trouble-shooting computers on both an amateur and a professional basis
for nearly 20.

On Oct 22, 4:36 pm, "Simon Templar" wrote:
> "Mark Trimble" wrote in message
>
> newsan.2007.10.22.22.41.33@127.0.0.1...
>
> > Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:
>
> >> When professional programmers get PAID for their labours, they put out
> >> KUALITY KODE. The same cannot be said for the part-time, unpaid, hippy
> >> amateur Linux coders.
>
> > If that is true, then explain this.
>
> > 1. Windows 3.0 was a graphical shell built around a 16-bit kernel which
> > was unable to address more than 640Kb of RAM without external programs to
> > support that addressing.
>
> True. This was to maintain compatibility with older DOS applications that
> relied on this behavior.
>
> > Windows Vista is a graphical shell built around
> > a 32- bit or 64-bit kernel which *is* unable to address more than 640Kb
> > of RAM without external programs to support that addressing.
>
> This is complete and utter bull****.
>
> > Linux
> > version 2.6 (the kernel, NOT any particular distro) addresses up to a gig
> > or more of RAM natively.How is Windows better.
>
> When it comes to address memory there is no significant difference between
> XP/Vista or linux. Your claim of XP/Vista not being able to address more
> than 640k is complete bull****.
>
> > 2. Most, if not all of the windows networking stack was and to this day
> > still is an after-thought (see windows 3.11 for workgroups for
> > explanation) which only partly works, based on the networking systems
> > built in to the linux/unix kernel at the time. How, then, is Windows
> > better.
>
> More bull****. The networking model in in the NT family of products (NT,
> Win2k, XP, Vista, etc) is not based at all on the Windows for Workgroups
> model.
>
> Once again you prove to be inadequately informed.
>
> --

Thanks Simon Templar--I was going to reply until I saw your post--I
agree 100%.

RL

On Oct 22, 6:13 pm, The Ghost In The Machine
wrote:

Thanks Ghost.

Seems you are either confused or don't know how to articulate your
thoughts.

>From both Wikipedia: http://en.wikipedia.org/wiki/Memory_management_unit

and this definition of virtual memory below, you can see the
following:

1) all x86 hardware uses MMUs to create, access and manage virtual
memory pages. Whether you run Linux or Windows on the x86 hardware
makes no difference--they all uses MMUs to break up accessing memory
into chunks. The only issue in virtual memory is this: will the
pages swapped be from upper RAM (faster), or, will they be from the
hard drive (much slower)?

2) all non-x86 hardware worth mentioning also use MMUs (this was news
to me). See Wikipedia above.

RL


virtual memory
Simulating more memory than actually exists, allowing the computer to
run larger programs or more programs concurrently. It breaks up the
program into small segments, called "pages," and brings as many pages
from disk into memory that fit into a reserved area for that program.
When additional pages are required, it makes room for them by swapping
them to disk. It keeps track of pages that have been modified so that
they can be retrieved when needed again.

If instructions in a very large program point back and forth to
opposite ends of the program, excessive disk accesses (thrashing) can
slow down execution if the entire program is not in memory.

Hardware Is Required
Virtual memory can be implemented in software only, but efficient
operation requires specialized hardware circuits. Most CPUs today
have memory management units (MMUs) that provide full support for
virtual memory.

Virtual memory claims are sometimes made for specific applications
that bring additional parts of the program in as needed; however, true
virtual memory is a hardware and operating

After takin' a swig o' grog, raylopez99 belched out this bit o' wisdom:

> On Oct 22, 4:36 pm, "Simon Templar" wrote:
>> "Mark Trimble" wrote in message
>>
>> newsan.2007.10.22.22.41.33@127.0.0.1...
>>
>> > Quoting raylopez99 on Mon, 22 Oct 2007 14:53:45 -0700:
>>
>> >> When professional programmers get PAID for their labours, they put out
>> >> KUALITY KODE. The same cannot be said for the part-time, unpaid, hippy
>> >> amateur Linux coders.
>
> Thanks Simon Templar--I was going to reply until I saw your post--I
> agree 100%.

*plonk*

--
Tux rox!

In comp.os.linux.advocacy, raylopez99

wrote
on Fri, 26 Oct 2007 04:01:49 -0700
<1193396509.299858.235050@19g2000hsx.googlegroups.c om>:
> On Oct 22, 6:13 pm, The Ghost In The Machine
> wrote:
>
> Thanks Ghost.
>
> Seems you are either confused or don't know how to articulate your
> thoughts.
>
>>From both Wikipedia: http://en.wikipedia.org/wiki/Memory_management_unit
>
> and this definition of virtual memory below, you can see the
> following:
>
> 1) all x86 hardware uses MMUs to create, access and manage virtual
> memory pages.

Pedant Point: the 8086 had no MMU. Not sure if the 80186
did either, but the 80186 took off like an overladen
albatross with a millstone around its neck, and plunked
itself into the metaphorical ocean.

As for creation of VM, that's an interesting philosophical
point, but both the 80x86 series and the 680x0 series use
a multilevel page table scheme.

> Whether you run Linux or Windows on the x86 hardware
> makes no difference--they all uses MMUs to break up accessing memory
> into chunks.

Actually, you're oversimplifying it. The MMU allows for
translation of a virtual address into a physical address;
the chunks, of course, are page addresses -- 4k or 16k,
depending on CPU. Intel's paragraph management scheme
complicates things slightly and I don't remember the
details on TSSs, LDTs and GDTs, but I'm old enough
to remember segmented address management in the PDP
11 family; the MMU therein required that segments be
physically contiguous, and each process had at most about
8 thereof (of which one had to be stack). MMUs in the VAX
and later on in Intel and Motorola processors (I believe
the 68020 had an MMU; the 68030 and 68040 certainly did)
allowed for a process to be scattered all over physical
RAM while still having contiguous virtual address spaces --
or non-contiguous virtual address spaces, as needs be.

> The only issue in virtual memory is this: will the
> pages swapped be from upper RAM (faster), or, will they be from the
> hard drive (much slower)?

There are other issues in the 80x86 series, most of
them thankfully dead. The old EMS specification, IIRC,
did some interesting tricks to allow access to E800:0000
(this was configurable but E800:0000 was the default)
from an arbitrary page somewhere in EMS. This presumably
was leveraged in the Win9x era, and finally eliminated
when NT became widely accepted in WinXP. I won't go into
conventional memory but Win9x had issues therewith --
most of them invisible.

I still don't know the details on the "A20 hack" but AFAIK
most modern x86 desktops depend on it.

>
> 2) all non-x86 hardware worth mentioning also use MMUs
> (this was news to me). See Wikipedia above.

http://www.homebrewcpu.com/

has no MMU. Of course it doesn't have Linux either. :-)

>
> RL
>
>
> virtual memory
> Simulating more memory than actually exists, allowing the computer to
> run larger programs or more programs concurrently. It breaks up the
> program into small segments, called "pages," and brings as many pages
> from disk into memory that fit into a reserved area for that program.
> When additional pages are required, it makes room for them by swapping
> them to disk. It keeps track of pages that have been modified so that
> they can be retrieved when needed again.
>
> If instructions in a very large program point back and forth to
> opposite ends of the program, excessive disk accesses (thrashing) can
> slow down execution if the entire program is not in memory.

More complicated than that, actually. Every element in a
classical linked list is a potential page fault. A walk
through a linked list, no matter where the elements are
in virtual memory, will result in page faulting if the
amount of information (virtual memory used thereby) is
greater than the amount of RAM.

Depending on the application, one can work with certain
clustering notions to attempt to limit page faulting.

>
> Hardware Is Required
> Virtual memory can be implemented in software only, but efficient
> operation requires specialized hardware circuits. Most CPUs today
> have memory management units (MMUs) that provide full support for
> virtual memory.

There are additional aspects to VM that are important.
All of these can be implemented in software, though not
nearly as reliably or as efficiently.

- Read/write vs. read/only vs. execute
Access control occasionally requires that certain memory
be marked read-only or execute-only. Execute-only is
good for code segments; readonly for data segments that
the application has no need of or no business modifying.
- Demand zero
The application may want memory that is already cleared.
A lot of systems have this option.
- Resource tracking and region sharing
This is mostly an issue with keeping track of what, as it
is typically cast as an interrelationship between tasks,
threads, or processes, and the virtual memory used thereby.
If two processes share the same physical page, and one of
the processes dies, the other process should not lose the
page, for example. Page sharing is (or should be) extremely
common for code segments, as they are non-writable and
usually used by multiple processes. In Linux sharing of
this sort is typically handled through shmem or mmap.
And of course, two processes can have the same virtual
address, but different physical addresses.
- Exception handling
If a processor attempts to read a virtual address
that's not in RAM, it will instigate a page fault
exception (I'd have to look up the details).
The kernel will then try to find space for that
page, throwing out already-existing pages to do so if
necessary. Writing or executing a virtual address may
also throw a page fault, if access permissions forbid
it; the kernel then has to do something intelligent
-- in Linux's case, sending a signal[*] which kills the
process; killing the process then notifies the parent
in a certain special way (SIGSEGV=11 gets translated
into wait3()/$? = 128+11 = 139), which the shell can
then translate into a somewhat meaningful diagnostic.
Arcane, yes, but workable.

>
> Virtual memory claims are sometimes made for specific applications
> that bring additional parts of the program in as needed; however, true
> virtual memory is a hardware and operating
>

Well, virtual memory is just that: memory that is virtual.
The hardware makes the process more efficient, and may
allow for additional capabilities such as what I've
described above without a lot of work on the application
writer's part.

I'm old enough to have implemented a JSR instruction in
an 1802, thank you very much. That's a software solution
(and a very slow one!) to what in most modern processors is
done in hardware or perhaps microcode -- even the 6502 had
a JSR instruction, but for some reason the 1802 did not.

(No, the 1802 didn't have an MMU, either.)

One could almost as easily implement a VMR and VMW in
the 1802, if one is willing to dedicate a register.
The software could then get arbitrarily creative in
fulfilling the request.
[*] signals were pioneered in Unix and are hard to describe
except that processes can catch them, block them,
and generally handle them. Signals are sent for
many common conditions, among them invalid memory
address, user interrupt, floating point exception,
and modem hangup.

--
#191, ewill3@earthlink.net
Linux. An OS which actually, unlike certain other offerings, works.

--
Posted via a free Usenet account from http://www.teranews.com

The Ghost In The Machine wrote:

< snip >

> I still don't know the details on the "A20 hack" but AFAIK
> most modern x86 desktops depend on it.
>

The "A20 hack" was quite simply a disabling of the A20 address line
the original 8086 had 20 address lines, A0 - A19 and could address 1 MByte
with it.
Now comes some weird stuff (for people not used to those old times): YOu
could set a Segment Reg to FFFF and then address the *first* 64Kbytes of
memory (less 16 Bytes) with that. The first 16 BYtes still lay in the FFFF
Segment, but the next 64K - 16Bytes actually wrapped to 0000.0000

Software existed which depended on that hack. For example, the original
GWBASIC coming from MS for MSDOS would *not* run if that address wrap would
not occur

Entroducing the 80286. It could address 16MBytes of Memory, having Address
lines A0 - A23
Here the Adress FFFF:0010 actually wrapped into the *second* MByte of
memory.
YOu could access 1MByte + 64 KBytes (-16Bytes) in Real Mode on that
processor. Normally no harm is done, you just have 64KBytes mem more
acessible than usually. But then some of the weird MS software no longer
ran.
For this reason alone the hardware makers decided to *disable* the A20 line
when in Real Mode. It was disabled using a line from the Keyboard
processor. Which was fine and dandy, there was just a small problem: That
processor was *slow* and it took eons to switch the A20 line.

Later chip-sets had a dedicated line for A20 dis/enable to make access to
memory above 1MByte faster

< snip >
--
Windows: Because everyone needs a good laugh!

In comp.os.linux.advocacy, Peter Köhlmann

wrote
on Fri, 26 Oct 2007 21:35:04 +0200
:
> The Ghost In The Machine wrote:
>
> < snip >
>
>> I still don't know the details on the "A20 hack" but AFAIK
>> most modern x86 desktops depend on it.
>>
>
> The "A20 hack" was quite simply a disabling of the A20 address line
> the original 8086 had 20 address lines, A0 - A19 and could address 1 MByte
> with it.
> Now comes some weird stuff (for people not used to those old times): YOu
> could set a Segment Reg to FFFF and then address the *first* 64Kbytes of
> memory (less 16 Bytes) with that. The first 16 BYtes still lay in the FFFF
> Segment, but the next 64K - 16Bytes actually wrapped to 0000.0000
>
> Software existed which depended on that hack. For example, the original
> GWBASIC coming from MS for MSDOS would *not* run if that address wrap would
> not occur
>
> Entroducing the 80286. It could address 16MBytes of Memory, having Address
> lines A0 - A23
> Here the Adress FFFF:0010 actually wrapped into the *second* MByte of
> memory.
> YOu could access 1MByte + 64 KBytes (-16Bytes) in Real Mode on that
> processor. Normally no harm is done, you just have 64KBytes mem more
> acessible than usually. But then some of the weird MS software no longer
> ran.
> For this reason alone the hardware makers decided to *disable* the A20 line
> when in Real Mode. It was disabled using a line from the Keyboard
> processor. Which was fine and dandy, there was just a small problem: That
> processor was *slow* and it took eons to switch the A20 line.
>
> Later chip-sets had a dedicated line for A20 dis/enable to make access to
> memory above 1MByte faster
>
> < snip >

Nicely explained. Hack upon bodge upon kludge, apparently.
I hadn't thought that anyone would actually be silly enough
to use the paragraph wraparound (since 0001:0000 = 0000:0010
in the 8086 days). Ye gods.

Ah, Amiga. The world could have been so different.... ;-)

--
#191, ewill3@earthlink.net
Conventional memory has to be one of the most UNconventional
architectures I've seen in a computer system.

--
Posted via a free Usenet account from http://www.teranews.com