Re: [Sheflug] Re: TopPage info for Sheffield Linux User Group

[Al Hudson <nospam [at] york.ac.uk>]

On Fri, 19 May 2000, Will Newton wrote:

> > > Yes, Windows API (eeeeurgh!)
> > 
> > What's specifically wrong with the win api then?
> 
> It sucks. Try using it and you will see.

I have used it. The only problem with it is that the documentation and
examples are all written by sixth formers (using hungarian notation, but
that's another rant ;). And it doesn't suck that bad - a lot of it is
extremely well thought out.

> Look through the manuals and see how many different ways you can rename a
> file with the Win98 APIs.

There's many different ways of doing the same thing, yes, but we're
talking about numerous different APIs used for different things. I can dig
out plenty of linux examples of the same thing if you like.

> And it's a moving target. (That's a moving, poorly documented target)

It's not moving that fast. Heck, even win3 calls still knock around. I've
had to go round my source putting in 32's and things in the function names
before, to try and keep the source current, so I know what it's like, but
there is a lot of compatibility in there. Changing pointers from far
pascal - you don't have to do it, but you can.

> > What do you mean by linux? GNOME code is designed for the GTK API (among
> > others), obviously that must be just as bad.
> 
> Apples != pears.
> I'm not sure about Wines internals, but I would guess things work like
> this
> Win32 function -> POSIX function -> syscall
> as opposed to
> POSIX function -> syscall
> Rocket science?

I wasn't aware GTK had been adopted as a POSIX standard....

> WIndows is NOT a GUI system, windowing toolkit or multimedia system, it is
> an OS.
> That means a lot more than drawing widgets. It influences
> programming methods on a much more fundamental level.

Depends which bits you are talking about. The Windowing section is the bit
that would require most wrapping; the other stuff maps in a fairly
one-to-one fasion. That was what I was talking about in terms of paradigm,
But if you're going to talk about 'linux' apis, I'll talk about 'windows'
apis ;) 'Linux' is NOT a GUI system, etc. etc. etc. 

> > No, it isn't.
> 
> Hmmm, I'm not sure. Windows is not a documented system. Wine tries to bug
> for bug "emulate" it's behaviour, which is where I believe it differs from
> a mere reimplementation. 

That doesn't make it an emulation. Emulation is something *very* different
in the common sense; what you are talking about is implementation. Wine
tries to bug for bug 'implement' it's behaviour - taking Windows as a
specification, they try to implement it. Okay, it's not documented (why
would it be? It's closed source), that just makes it a clean-room
implementation.

> > Why can't Wine take advantage of Linux specific stuff? It's just an
> > API....
> 
> No. When you use GTK/Qt/whatever other ill founded example you care to
> name you also use POSIX calls for things like file I/O, you use STL for
> strings etc. Windows has pointless replacements for many of these things,
> and whether it is some MS guideline or not, almost none of the Win32
> source code I have seen has used POSIX. Yep. Not even fopen(). Not even
> strcpy(). Don't ask me why.

Not necessarily, no. Have you used Qt? I have. And I don't use strcpy().
Heard of QStrings? I can think of loads of examples. It's not good enough
simply to say "Well, Windows does all these things differently, so mapping
those function calls to POSIX (or whatever) will incur a big overhead not
worth paying", because it's simply not true. People do that all the time,
already.

> Java? Heh, well we all know what happened to Java don't we.
> It's so slow it hurts, and in 10 years time the only people using it will
> be Sheffield University DCS.

I think you've obviously missed the point with Java then ;) Never mind,
we'll all be using Java and you can stick with the ancient stuff ;)

> > Not really. A lot of Wine is wrapper; it doesn't provide functions, linux
> > does.
> A function call overhead at least. On small functions this could add up
> to a considerable percentage of running time.

A considerable percentage?? How? Let's take an example. Calling an
subroutine: caller saves state. PUSHF, PUSH (whatever registers) or a more
complete save to stack. JMP subroutine. Do stuff. RET. POP.. Maybe fifty
extra assembler instructions? Of course, it may be more complicated than
that (a lot of Win32 is {quasi}C++, therefore the function may be doing
more than that before branching), but people do it already. 

> > Using released Wine binaries? They're all compiled -g aren't they?
> http://wine.dataparty.no have some stripped builds from CVS.
> (URL may be wrong)

Is that what you use?

> > You can choose.
> 
> I can only ever get Win16 style window decorations whatever I have the
> config set to.

Then you have a problem with your Wine setup I'm afraid ;)

> I don't. I have a problem with reinventing the wheel though. And that is
> what most of the WIndows code seems to do. I prefer only one wheel to be
> present on my computer. :)

I'm afraid it's tough luck for you then, because I can tell you your
computer is chock full of wheels ;)) GTK wrappers, qt wrappers, python
wrappers, POSIX (pthreads as an example), etc. etc. The list goes on..
why? For compatibility. For usefulness. Some things are better at task a,
others better at task b. The number of libraries you'll have installed on
your system that do the same task, or broadly similar tasks, will be quite
large I'm afraid ...

Cheers,

Alex.




---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.