Re: LTspice
From: ldg (asfd_at_hotmail.com)
Date: 03/26/05
- Next message: Fernando: "Protel negative"
- Previous message: Robert Baer: "Re: Problems with SPICE models from vendors"
- In reply to: Ken Smith: "Re: LTspice"
- Next in thread: ldg: "Re: LTspice"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 25 Mar 2005 21:22:00 -0800
On Fri, 25 Mar 2005 22:00:04 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) wrote:
>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.
>
>--
Thanks for the thoughtful reply!
Regards,
Larry
- Next message: Fernando: "Protel negative"
- Previous message: Robert Baer: "Re: Problems with SPICE models from vendors"
- In reply to: Ken Smith: "Re: LTspice"
- Next in thread: ldg: "Re: LTspice"
- Messages sorted by: [ date ] [ thread ]