Re: LTspice

From: Ken Smith (kensmith_at_green.rahul.net)
Date: 03/25/05 

Date: Fri, 25 Mar 2005 22:00:04 +0000 (UTC)

In article <1jrt31dugusf979slo3ndso49t0opn1kkv@4ax.com>,
ldg <asfd@hotmail.com> wrote:
[....]
>Actually, I was wondering how wine itself works as an emulator.

Wine works very well indeed as an emulator even though it is in fact not
an emulator but a port of the windows API onto linux.

> I'm
>supposing it adds another layer between the application and the
>hardware and would incur some overhead. Is this not the case?

Consider the case of a request to write to a file:

The typical Windows application does this:

(1) The object that is requesting to be written calls its virtual method
    that is used for writing.

(2) The write virtual method calls the virtual method for each of its
    component parts.

(3) Each component part calls the virtual method that is part of the file
    handling stuff in MFC.

(4) The file handling stuff creates the needed structure to pass to the
    windows API.

(5) The windows API recieves the request and burries it in warm peat for
    aging.

(6) The windows API hands the request to the 32 bit DOS function.

(7) The 32 bit DOS function calls the section of the device driver that
    does writing

(8) The device driver waits for the tubes in the disk drive to warm up and
    then dribbles the data into the srive.

Under wine, items 5 to 8 change to this:

(5) The wine code recieves the request.

(6) wine passes the request to the kernal function

(7) The kernal transfers the data to a buffer and flags it as needing to
    be written.

(8) When time permits or there are not enough buffers left, the Kernal
    calls the code for writing on this type of disk.

(9) The write actually happens.

>>Some companies have good programmers and others don't. In some cases, it
>>isn't that the software will not work just fine on some other system, it
>>just that the maker only tests it on one version and makes their install
>>script test for that specific version.
>>
>
>So you have to solve the problem caused by the various distro vendors
>by writing different install scripts?

In many cases, it is just a matter of using the software from the good
programmers and ignoring the software from the bad ones.

> I believe there actually is an
>attempt to solve this problem by normalizing the libraries so 3rd
>party software can always find them.

It is less about normalizing and more about picking a minimum standard and
going with that.

<RANT>
Bad programmers assume that the target machine has all the latest stuff.
Good programmers only enforce the requirements that actually matter in
their code. Bad programmers hard code the locations and versions of
everything. Good programmers allow for things to be specified at install
time.
<\RANT>

> This seems like a better
>solution, but so far the various vendors haven't complied. Redhat
>probably thinks their user base is "captured" by the way they have
>these libraries arranged. The other vendors apparently refuse to
>follow Redhat.

Dead Rat has lots of silly ideas. But then so do lots of other folks.
Altera just brought out a version of Quartus that runs under Linux, if you
have the right version of Read Hat and if you have the right version of QT
and if you have the right version of Glibc and if you place your left hand
on top of your head while you install it. All Quartus really is, is a
compiler and a text editor. They could have left the editor out. There
is no reason a compiler needs any such specifics about the machine it will
run on.

[...]

>One of the issues with switching to linux is that 3rd party software
>vendors seem to not want to port their code to it. Nero did recently
>and has been taking flack because their code is proprietary. If the
>linux community wants linux to grow, they should encourage such
>things. It also means they should take steps to ensure easy
>operability between distros I think.

Nero comes free with many DVD burners etc. The free version is not the
Linux version. I think this is why they are getting flack. If they gave
you the Linux version when you bought the DVD burner, most users would not
care that they did not get the source code.

[...]
>So far I've tried Fedora, Xandros, and SuSE. SuSE seemed to set up
>the hardware more easily, though Xandros was also very good. Using a
>memory stick on Fedora meant creating a special mount directory and
>going through that process. SuSE and Xandros seemed to just recognize
>a memory stick automatically. Only Xandros automatically set up Samba
>so that it would function on my lan with win2k machines.

My work machine runs SuSE 9.2. It almost got samba right on the first
try. At home I run SuSE 8.2. The samba set up in it was completely
broken. There are signs of progress. 

-- 
--
kensmith@rahul.net   forging knowledge