Re: keyboard/mouse programming
- From: s_dubrovich@xxxxxxxxx
- Date: Sat, 1 Dec 2007 16:02:41 -0800 (PST)
On Dec 1, 10:59 am, "Rod Pemberton" <do_not_h...@xxxxxxxxxxxxx> wrote:
<s_dubrov...@xxxxxxxxx> wrote in messageNeither am I, and as the Canopy group wasn't sharing any proceeds with
news:a64e8eff-437f-4fcf-90f3-2c1472f4df8e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Nov 28, 5:01 am, "Rod Pemberton" <do_not_h...@xxxxxxxxxxxxx> wrote:
"Robert Redelmeier" <red...@xxxxxxxxxxxxxxx> wrote in message
news:9n73j.27769$Pv2.9035@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
So? Raising your competitors cost of doing business is a
standard American corporation practice.
Rather cynical: RRC (Raising Rivals Costs) is an illegal
anticompetitive business practice (even if hard to prove):
http://ftc.gov/be/RRCGMU.pdf
that30 pages... Does it specifically say that's illegal somewhere or just
they have conducted research into the practice from an anticompetitive
perspective such as by a firm believed to be monopolistic?
The few sections I skimmed seem to indicate that this research is highly
theoretical in nature and different from predatory pricing, monopolistic
practices, and even anticompetitive practices. I.e.,:
[snipped]
Thought you might be interested in:
http://www.maxframe.com/
Re:CALDERA, INC., Plaintiff, vs. MICROSOFT CORP., Defendant.
On second thought, perhaps you've seen it.
But as to RRC...
"
In addition to its improper vaporware and FUD campaigns, Caldera
alleges that Microsoft also forced OEMs away from DR DOS 5.0 by what
plaintiff refers to as the "licensing triple-whammy," which refers to
(1) per processor licenses, (2) minimum commitments subject to
forfeiture, and (3) increased license duration. Per processor
licensing agreements required an OEM to pay Microsoft a royalty on
every machine the OEM shipped regardless whether the machine contained
MS-DOS or a different operating system. This is in contrast to a per
system licensing agreement, which required OEMs to pay a royalty on
only those computers shipped with MS-DOS installed. The use of per
processor agreements is argued by plaintiff to be Microsoft's most
effective single weapon against DR DOS. Plaintiff alleges that DRI had
no realistic chance to license DR DOS to OEMs under a per processor
license with Microsoft. It would make no sense for an OEM to install
DR DOS when it had already paid for MS-DOS on every machine. Microsoft
contends that OEMs were free to depart from the per processor
licensing scheme, and that price differentials between license types
were "relatively minor." However, plaintiff points to the depositions
of several OEM executives who testified that even slight price
differentials between the per processor and per system licenses meant
that only the per processor license was financially viable.
"
I'm remember reading about. I'd say, while raising competitor's costs, this
only proves existing illegal anti-competitive behavior, not that RRC
specifically is illegal. Hey, I'm not lawyer...
me, I haven't much interest. It was just that I ran across it on a
search while browsing this thread and it seemed abit apropos.
What's up with that assembler you were working on?The translator, small-c to nasm, is parked due to ABI review.
The Q arose on how to handle the implementation of; return (y); .. the
information I've run across to date says: place the value in a
register, like eAX. But register values make a subroutine non-
reentrant, so I was taken aback by this. Wherefore art thou stack-
frame. Options and proposals corrode from there. This sparked an
architecture review (of my hobby os) and more generally, code
housekeeping. Since the effort was to explore a notion of HLL support
to my hobby os, of which small-c is an imperfect start, a measure of
'proof of concept' exists, but economy of further effort is in
question for now.
Have you used aeBIOS forI haven't gotten into it as much as you have. I think you've said
anything useful?
you've done a fair amount of testing. It figures that the first
subroutine I tried to port to it (int15h ax.E820h) isn't returning a
full Address Range Descriptor, just the base address is returned, so
I've more to do to look at why, but aeBios isn't really a focus.
While kudos are due Mike, aeBios doesn't reflect the architecture I'm
after; multi-sectioned code&data, pl0..3. Mike's way is probably
superior, flat PM, but, well, I'm stubbon, I have to determine it
myself. I'm sure I'll be returning to aeBios for testing PM bits.
Steve
Rod Pemberton- Hide quoted text -
- Show quoted text -
.
- Follow-Ups:
- Re: keyboard/mouse programming
- From: Rod Pemberton
- Re: keyboard/mouse programming
- References:
- Re: keyboard/mouse programming
- From: Rod Pemberton
- Re: keyboard/mouse programming
- Prev by Date: Re: Sudoku
- Next by Date: Re: Sudoku
- Previous by thread: Re: keyboard/mouse programming
- Next by thread: Re: keyboard/mouse programming
- Index(es):
Relevant Pages
|
