Invisible wrote:
> I mean, an MP3 player isn't exactly a complex piece of hardware. There's
> a battery, a harddrive, a processor, and a DAC. I would think those are
> all off-the-shelf components. Just stick them in a box, put in the 3
> microswitches for the buttons, and your hardware is done.

Many have special chips to do some steps of MP3 decoding. Or MPEG4 video
decoding!

Post a reply to this message

Darren New wrote:
>  > Every bug and glitch has to be precisely
>> replicated, or some lump of software somewhere that depends on those 
>> bugs won't work right.
> 
> Only the bugs and glitches that some piece of software you want to 
> support depends on needs to be implemented.

Actually, even more. It's obvious that WINE leaves *tons* of stuff 
unimplemented. CreateFile() does not update performance counters, doesn't 
check group policy, probably doesn't do *any* sort of security checks 
(beyond what Linux does), doesn't write audit logs, and maybe doesn't 
support UNC path names, probably doesn't support the various flags that 
CreateFile() natively supports like surpressing read-ahead or locking the 
file from deletion, probably doesn't support compressed or encrypted files, 
doesn't update any sort of USN logs, and so on.

So it's clear it's not necessary to duplicate the API precisely. You only 
have to duplicate it well enough to fool the software using it. You probably 
don't have to distinguish between (for example) not having permission to 
open the file and not having permission to traverse the directories above 
the file.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Mueen Nawaz wrote:
> 	You don't buy that it *could* be a huge headache? If you think a
> counterexample suffices to make your case, I can start itemizing quite a
> few real cases where it was a headache.

Or, as is common in my circle to say, "The plural of anecdote is not data."

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Wow, long thread...

Post a reply to this message

On Tue, 16 Dec 2008 07:38:51 +0000, Orchid XP v8 wrote:

>>> Besides, I was under the distinct impression that it's *illegal* to
>>> reverse-engineer Windows.
>> 
>> Probably not. IANAL, but the last lawsuit I looked at in the USA, if
>> you copyright the code, then someone else can reverse engineer it.
> 
> And the part in the EULA that says "you must not reverse-engineer
> this"...?

is a shrink-wrap license that is probably not enforceable.  I don't 
believe it's been tested in court yet, though.

But it is (AFAIK) legally questionable at best, intended to get people to 
comply through intimidation.

Jim

Post a reply to this message

Darren New wrote:
> Mueen Nawaz wrote:
>>     You don't buy that it *could* be a huge headache? If you think a
>> counterexample suffices to make your case, I can start itemizing quite a
>> few real cases where it was a headache.
> 
> Or, as is common in my circle to say, "The plural of anecdote is not data."

	Do I have your permission to put that as a tagline in my sig?
Attribution will be included, if desired.

-- 
BREAKFAST.COM Halted... Cereal Port Not Responding.


                    /\  /\               /\  /
                   /  \/  \ u e e n     /  \/  a w a z
                       >>>>>>mue### [at] nawazorg<<<<<<
                                   anl

Post a reply to this message

On Tue, 16 Dec 2008 09:20:47 +0000, Invisible wrote:

> Jim Henderson wrote:
> 
>>>> Text mode X11 configuration apps have been around for a while, longer
>>>> than sax2, in fact.
>>> ...which is of no help whatsoever if you can't *find* them.
>> 
>> http://letmegooglethatforyou.com/?q=x11+text+mode+configuration
> 
> ...which again requires Internet access.

...which you happen to have, otherwise you wouldn't be reading this 
message, would you?

>>> (Actually, at the time I tried out klogic, we *did* have an Internet
>>> connection, but I didn't even bother to *attempt* to make it work
>>> under Linux. Making the "simple" stuff work was hard enough...)
>> 
>> Well, then, there's really no excuse for not submitting bugs, is there?
>> ;-)
> 
> How do you figure that?

Because you're on the 'net now?

>> Tux Racer has been around for dog's ages (the last *update* is 7 years
>> ago, in fact).  "Not much" isn't a good assessment unless you've bought
>> into the FUD.
> 
> I guess for a suitable definition of "not much" you could argue it
> doesn't apply. After all, 3 is greater than 4 for sufficiently large 3.
> :-P

It's not 6, let's put it that way.  It's a number significantly larger 
than 6.  Go up to freshmeat.net and do a search on "games" and see how 
many hits you get.  That's a *start*.  Go look at the online repositories 
for OSS games for openSUSE, Fedora, Ubuntu, etc.  That's a start.

The way you write, you make it sound like there's maybe 1 or 2 or maybe 
even *gasp* as many as 10 whole games for Linux.  There are probably 
thousands that run natively, and hundreds to thousands more that will run 
under something like WINE or reasonably within a current release of 
VMware.

>>> Weirdly, almost all of Valve's games run on Linux - or rather, the
>>> GAME SERVER runs on Linux. The clients are Windows-only. (In fairness,
>>> what does a game server do? It sends and receives UPD datagrams. Can't
>>> be *that* hard to port it. Drawing 3D graphics is another matter...)
>> 
>> Not if you use a crossplatform library like openGL or Mesa.  Plenty of
>> people write games that use those libraries.
> 
> Both of those only support graphics. A game also needs sound, complex
> keyboard access, realtime control, etc., all of which varies by
> platform.

And there are open alternatives to DirectSound or whatever it's called.  
Sheesh, you talk about 3D graphics so I answer it, and then you conflate 
graphics with sound.  There are standard libraries that work 
crossplatform for that at a reasonable spead.  OpenAL for sound, for 
example.

> I'm not saying it's impossible to make cross-platform games. But when
> you have a huge codebase invested in DirectX, it would be tantamount to
> a complete rewrite to move to OpenGL. (Plus Valve games make use of lots
> of advanted stuff like DirectX 10. Guess where that's supported...)

If you want broader platform support, then it becomes an investment to 
look into.  And companies are doing it, as you said, Valve releases games 
that are native on Linux now.  There must be money in it or they wouldn't 
invest.

>>> So you've got several GB of data, and you can only pick apart a few
>>> dozen bytes of it per day. Sure, shouldn't take long.
>> 
>> It's not about the complexity, it's about the concept.  And the tools.
> 
> Of course, why would complexity be any obsticle to comprehending
> something?

It shouldn't be an obstacle to trying to comprehend it.  I just pulled 
down about 300 MB of source code for a product my employer develops.  It 
would take me a year to study it enough to be able to develop code for 
it, and it's not part of my job.  But that doesn't stop me from using 
Source Navigator NG3 (a really cool program for code analysis - and BTW 
it's GPL'ed software) and looking at specific issues through the lens of 
the source code.  It's a chance to learn.

If you start with "this is so incredibly complex I'll never understand it 
so why even bother starting to look at it", then sure, it's going to look 
damned impossible.  You won't understand it overnight, but you can learn 
about it over time.

<joke>I thought Americans were the only ones who looked for instant 
gratification.  <sigh> </joke>

>> Reverse-engineering is not generally illegal.
> 
> Sure. The fact that the EULA says "you may not reverse engineer this"
> doesn't make it illegal at all. No sir.

EULAs are AFAIK not court-tested, and are highly suspect in their "shrink-
wrap" or "click-wrap" form.  So yes, doing reverse engineering even after 
being forced to agree to an EULA is not generally illegal.  It may be a 
violation of the terms of the license if the license is upheld in court.

There is a *huge* difference there, and local laws may vary.  For 
example, in Germany, I think you'll find that reverse-engineering is 
generally accepted as standard practice and no German court would enforce 
an EULA that prohibited it.  In China, well, you're in China.  The 
government is pretty well known to sanction reverse-engineering of all 
sorts of things, from aircraft airfoils to software to painting equipment.

>> In that, you have one team that determines the specs.  You compile a
>> specification for those functions.
>> 
>> Then you turn the specifications over to a second team that has not
>> looked at the code for the original and have them reimplement it.
> 
> Given how painfully difficult it is just working out how to *use* the
> Win32 API, the chances of somebody correctly implementing a clone of it
> seem vanishingly small. (Especially given the vast sea of software that
> intimately depends on undocumented functionallity, glitches and the
> like.) Also, I hear that various M$ products depend on entire APIs which
> are kept "secret".

Difficult for you != difficult for everyone on the planet.  'nuff said.

>> That's how we ended up with clone PCs - clean room reverse engineering
>> of IBM's BIOS.
> 
> Because the BIOS *totally* has the same complexity level as an entire OS
> with 20 years of backwards compatibility.

<sigh>  Again, it's not the specifics, it's the concepts.  A more complex 
OS just takes more time and manpower.  That doesn't make it impossible.  
If it wasn't impossible, WINE woudn't exist.  WINE exists.  Therefore, 
it's possible.

>> Have a look at WINE's FAQ about Windows patents and whatnot.  You'll
>> learn a lot.
> 
> I don't see anything in the FAQ about legallity.

I was sure there was something in there.  No matter, look at Mono - it 
also addresses the patent issue.  Mono is a reimplementation of the .NET 
framework - incidentally, done (I believe) through clean-room reverse-
engineering.  The developers of Mono were originally denied access to the 
Microsoft Professional Developer's Conference, but Microsoft *couldn't* 
prosecute them.  The project leads work for Novell so they do benefit 
(again, I understand) from the agreement between Microsoft and Novell, so 
the threat isn't really there now, but the development model hasn't 
changed just in case the agreement does change.

Same with Moonlight (a Silverlight-compatible clone, written in Mono 
IIRC).

Etc, etc, etc - there are plenty of examples out there.

So please stop saying "it's impossible!" when clearly it isn't because 
it's being done.

Jim

Post a reply to this message

On Tue, 16 Dec 2008 20:09:30 +0000, Orchid XP v8 wrote:

> No - has has to be "incorrect" in exactly the same way that Windows
> implements it incorrectly. Every bug and glitch has to be precisely
> replicated, or some lump of software somewhere that depends on those
> bugs won't work right.

Now I'm going to break your brain.

http://www.reactos.org/en/index.html

Jim

Post a reply to this message

On Tue, 16 Dec 2008 17:33:16 +0200, Eero Ahonen wrote:

> I use :wq (or :wq!, if :wq complains that the file is write-protected
> :p).

That's the one I was trying to remember. :-)

Jim

Post a reply to this message

On Tue, 16 Dec 2008 08:54:50 +0000, Invisible wrote:

> Jim Henderson wrote:
> 
>> User error.  He didn't know how to exit vi with shift-ZZ or :q! or :w!
> 
> One might argue "designer error" for making the system so non-obvious to
> operate. :-P

It's obvious once you learn to operate it.  Consider the history of vi - 
dumb terminals.  No ANSI.  No GUI.

But a man page.  "man vim" is a good starting place on a modern *nix 
system for learning how to use vi.

Jim

Post a reply to this message