|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
86.131.100.226
It is many years since I was seriously involved in PC programming so I may have forgotten, or things may have changed radically, BUTmy understanding of DLLs is that they are shar(ed)(eable) libraries of routines.
A given DLL will be loaded by the first app that requires it. Other apps that need it will check that it is there before loading another copy.
I am not sure what is responsible for unloading DLLs when they are no longer required but, logically, there must be a DLL manager in the OS.
Once loaded a DLL doesn't DO anything, ie doesn't consume processor unless a routine is being called. Even then I cannot see any difference between the routine being in the DLL or the main .EXE
Basically it sits there lurking in memory .....
So why the expressed concern about seeking and destroying all DLLs?
Follow Ups:
> It is many years since I was seriously involved in PC programming so > I may have forgotten, or things may have changed radically, BUT
> my understanding of DLLs is that they are shar(ed)(eable) libraries > of routines.Yep. They can also contain executable/runnable code, see below.
> A given DLL will be loaded by the first app that requires it. Other > apps that need it will check that it is there before loading another > copy.
Yep. They can also be executed standalone, by the rundll system application, but they need to be specially designed to do this, and I think the practice is frowned upon nowadays.
> I am not sure what is responsible for unloading DLLs when they are no > longer required but, logically, there must be a DLL manager in the > OS.
The OS takes care of loading and unloading DLL's. In Linux it's an app called ld, in MacOS X it's dynld, in Windows it's just called the loader.
> Once loaded a DLL doesn't DO anything, ie doesn't consume processor > unless a routine is being called. Even then I cannot see any > difference between the routine being in the DLL or the main .EXE
Actually, once the process that requires the DLL terminates, the loader usually unloads the DLL.
> Basically it sits there lurking in memory .....
Sometimes, if it's not written very well, or the host process terminates poorly and doesn't release the DLL's resources. But usually
the loader is pretty smart and unloads the DLL if the host process goes away, or if the host process calls for the DLL to be unloaded explicitly. Keep in mind that, unless it's stuck in some sort of loop that's keeping resources open, the DLL does nothing unless there's an app actively calling it's functions. It may eat up some memory, however.> So why the expressed concern about seeking and destroying all DLLs?
Because people don't understand how computers work.
> What am I misunderstanding / missing?
People think that a computer behaves just like any other piece of audio gear, and that you can significantly alter the way it works by futzing around with completely unrelated software.
/*Music is subjective. Sound is not.*/
DLL is a Windows specific concept. Other operating systems have similar but not exact analogies. Unix/Linux for example have the concept of shared libraries, but it's not quite the same as DLLs. Many of your comments only apply to Windows DLLs.*** People think that a computer behaves just like any other piece of audio gear, and that you can significantly alter the way it works by futzing around with completely unrelated software ***
A little knowledge can be a dangerous thing.
It's important to have an open mind and realise Windows and related applications are very complex, and in many cases non-deterministic (at least, not without deep understanding of the interaction between components).
I can actually think of quite a few cases where loading/unloading a DLL may impact the sound quality. For example, a DLL may be keeping an open connection to the sound device (for the purposes of issuing notification alerts) - if you want to ensure there's no spurious junk overlayed onto the music, or forcing the device to switch sample rates or resample, you may want to ensure there are no other open connections to the audio device.
A DLL may also be part of a device driver (yes, device drivers in Windows are implemented as DLLs, whether in user mode or kernel) that is servicing interrupts for a device that is sharing the same PCI IRQ level as the audio device. A badly written DLL may cause glitches to the audio playback (if you scan the internet, there are lots of people complaining about crackling in the sound and they usually have no idea how to solve it).
A DLL may even be servicing a completely unrelated device on a different IRQ level but with a high PCI latency - it hogs the PCI bus for too long, again causing problems with audio. A common problem is video cards, which are normally configured with high latency values due to the high throughput required for graphics.
There are lots of examples like these - I wouldn't rule out the possibility that loading and unloading a DLL may impact the sound, but understanding the reason may require a fairly deep knowledge of exactly what is happening in the system.
> DLL is a Windows specific concept. Other operating systems have > similar but not exact analogies.Yep, but as far as the end user is concerned, it's a file with some routines that apps use.
> It's important to have an open mind and realise Windows and related
> applications are very complex, and in many cases non-deterministic > (at least, not without deep understanding of the interaction between > components).True. However, in my experience, if something breaks in windows it breaks *hard*. You get obviously distorted audio, or video, or corrupt files, or crashiness, or some similar result. I've never had a software compatability issue slightly tint the colors on my screen, or EQ my audio playback, or some other such minor change.
> I can actually think of quite a few cases where loading/unloading a > DLL may impact the sound quality. For example, a DLL may be keeping > an open connection to the sound device (for the purposes of issuing > notification alerts) - if you want to ensure there's no spurious junk > overlayed onto the music, or forcing the device to switch sample > rates or resample, you may want to ensure there are no other open > connections to the audio device.
Right, however if there's a sample rate issue you're going to hear it right away, usually it plays back REALLY slow. Otherwise, if something else is holding an audio channel open for some stupid reason, as long as it's not actively playing a sound, no data will get mixed into the audio stream. I'm not sure where "spurious junk" will come from, either there's audio data being played or there isn't.
> A DLL may also be part of a device driver (yes, device drivers in > Windows are implemented as DLLs, whether in user mode or kernel) that > is servicing interrupts for a device that is sharing the same PCI IRQ > level as the audio device. A badly written DLL may cause glitches to > the audio playback (if you scan the internet, there are lots of > people complaining about crackling in the sound and they usually have > no idea how to solve it).
I find that's usually a hardware compatability issue, coupled with lousy drivers. VIA chipsets are notorious for this. However, it's still a VERY obvious problem.
> A DLL may even be servicing a completely unrelated device on a > different IRQ level but with a high PCI latency - it hogs the PCI bus > for too long, again causing problems with audio. A common problem is > video cards, which are normally configured with high latency values > due to the high throughput required for graphics.
Again, that's more of a hardware compatability issue than a DLL issue. If you aren't moving a whole lot of video data around (HD video playback, 3d gaming, etc...) playing audio shouldn't be an issue at all. If you are draining the soundcard buffer due to PCI bus latency issues, then stuttering audio is probably the least of your worries.
> There are lots of examples like these - I wouldn't rule out the > possibility that loading and unloading a DLL may impact the sound, > but understanding the reason may require a fairly deep knowledge of > exactly what is happening in the system.
My contention isn't that unrelated software cannot affect the audio, but that such an issue would be patently obvious. If ZoneAlarm is going to mess with your audio, it's going to do it in a big way, like, in a staticky garbage playback way. It isn't going to slightly narrow the soundstage or remove sparkle from the percussion section.
PS - My background is in high speed data aquisition and playback, where moving HUGE amounts of data around strict timing tolerances is critical. Pretty much 100% of the time, the system would either work or not work. You'd either get clean data or distorted gibberish. In very rare situations you'd get wierd one-bit errors, but we're still talking about a bit error rate in the area of 1e-10 (one error every several trillion bits)
/*Music is subjective. Sound is not.*/
*** Yep, but as far as the end user is concerned, it's a file with some routines that apps use. ***No, not really, hence the widespread misunderstanding. DLLs in Windows are *not* just a passive collection of shared routines, unlike a Unix .so library. DLLs in Windows can also behave similarly to "kernel modules" in Linux, and service interrupts or run a polling loop.
*** However, in my experience, if something breaks in windows it breaks *hard*. ***
Not my experience at all.
*** Right, however if there's a sample rate issue you're going to hear it right away, usually it plays back REALLY slow. ***
Not really, because Windows and/or the device driver resamples. Problem is, sometimes you can't control when resample happens. In theory, AC97 always resamples everything to 48kHz, but many prosumer audio cards have a WDM driver implementation that allows the default sample rate to change (ie., intentionally breaking AC97).
Imagine the following situation - a driver that allows the base output sample rate to change, and resamples all open connections to this rate (usually the rate is determined by the first open connection). Ie. if an application opens the driver in 44.1kHz, the driver will set the sound card to 44.1. Then if another application also simultaneously opens a connection at a different sample rate (say 48kHz), the driver will now silently resample this second connection to 44.1kHz as the first application is still open.
Now if during startup an app or DLL plays a Windows system sound (usually at 22.05kHz) but for some reason keeps the connection open. Then you open your sound playback application and play a CD at 44.1kHz. The driver will resample your CD to 22.05kHz!!! This has actually happened to me a few times with a particular sound card, and it took a while to isolate how this behaviour came about.
This is an example of behaviour that will cause degradation in sound quality, but the degradation may not be immediately obvious, and it's *not* a hard failure, but everything working as designed.
*** I'm not sure where "spurious junk" will come from, either there's audio data being played or there isn't. ***
I'm getting the feeling that you do not have a lot of experience, because your statements show some naivity.
Again, consider the situation where a background task (again, this is a real example) periodically opens and closes an audio connection - possibly because it is polling something, and playing an alert tone depending on a condition, but even if there's no alert, it opens and closes the audio device anyway but sends a blank audio file (poor programming practice, but hey there's some stupid people out there).
This will cause "spurious junk" to be overlayed onto the audio being played back, depending on how the application opens and closes the audio device, and the device driver. And don't forget many applications like to keep the sound device open permanently, hence making driver resampling very likely.
Typically, in real life, this "junk" usually comes about from Windows system sounds, which is why it's a really good idea when building a digital audio workstation (and I have built several) to have a different device (ie. the motherboard audio device) act as the default multimedia device, and have a second dedicated audio device (that Windows doesn't see or touch) for music.
*** I find that's usually a hardware compatability issue, coupled with lousy drivers. ***
Maybe, maybe not. And the problem may not may not obvious, despite what you think. For example, increased jitter due to PCI bus contention may not immediately translate to stuttering or gaps in the sound, but it will cause a degradation to the sound.
*** My contention isn't that unrelated software cannot affect the audio, but that such an issue would be patently obvious. ***
In my experience, your contention is not true. I have already described several examples where the issues are not patently obvious. For example, not many people can immediately tell when 44.1 is being resampled to 48 and vice versa. But it *will* result in degradation of sound.
*** My background is in high speed data aquisition and playback ***
And *my* background is designing and building large complex systems where the interactions between different components are so complex they appear to be non deterministic and sometimes downright illogical. I have also written a thesis on computer music, and built a very early computer music real time performance system. I have also participated in distributed operating system research in the 80s, as well as early work on digital room correction. I have also written several device drivers. Of course, most of these feats happened very early in my career, these days I manage a team of people who manage the designers who then manage the developers, but it's always good to have a strong technical background, especially since I'm ultimately accountable for the overall architecture of the organisation.
> No, not really, hence the widespread misunderstanding. DLLs in Windows are *not* just a passive collection of shared routines, unlike a Unix .so library. DLLs in Windows can also behave similarly to "kernel modules" in Linux, and service interrupts or run a polling loop.Right, but they don't just load themselves into memory to service an interrupt, they are called to monitor an interrupt by an application or system service via ntdll.dll, or whatever they are calling it these days. Keep in mind I'm referring to those who claim exiting out of mcafee or zonealarm improves the sound of their media player, and looking at Process Explorer I don't see either one of those loading winmm.dll. Could they be trapping some other system call and degrade timing precision in some real-time process? Possibly, but I haven't seen it affecting an 8Mbps RS422 link running for two weeks straight.
> I'm getting the feeling that you do not have a lot of experience, because your statements show some naivity.
Well now that's a bit presumptuous.
> Again, consider the situation where a background task (again, this is > a real example) periodically opens and closes an audio connection - > possibly because it is polling something, and playing an alert tone > depending on a condition, but even if there's no alert, it opens and > closes the audio device anyway but sends a blank audio file (poor > programming practice, but hey there's some stupid people out there).
How often do you see this? I've done loads of long-term testing playing audio files with kernel streaming, with bit-perfect results (comparing lossless file decompressors into a virtual soundcard) WDM will mess with your output, though I haven't seen any conclusive evidence that it's readily audiable.
> Maybe, maybe not. And the problem may not may not obvious, despite what you think. For example, increased jitter due to PCI bus contention may not immediately translate to stuttering or gaps in the sound, but it will cause a degradation to the sound.
C'mon, if the PCI bus is so laggy that it's draining the buffer of your sound card (probably the slowest device on the bus), you'll be noticing some effects other than degraded sound. Probably crashing, as PIO requests from other devices on the southbridge queue up and pound the memory controller.
> In my experience, your contention is not true. I have already described several examples where the issues are not patently obvious. For example, not many people can immediately tell when 44.1 is being resampled to 48 and vice versa. But it *will* result in degradation of sound.
44.1KHz being resampled to 48KHz WILL result in a degradation of sound? That's an interesting contention.
> And *my* background is designing and building large complex systems where the interactions between different components are so complex they appear to be non deterministic and sometimes downright illogical.
Ever deal with enterprise java programming? :)
> I have also written several device drivers.
Yep, I miss DOS, too.
/*Music is subjective. Sound is not.*/
*** Well now that's a bit presumptuous. ***Hey, if you quack like a duck ...
*** How often do you see this? ***
At least once. Remember, in order to disprove your "contention", all I need is *one* counterexample. Which I have provided.
*** I've done loads of long-term testing playing audio files with kernel streaming, with bit-perfect results (comparing lossless file decompressors into a virtual soundcard) WDM will mess with your output, though I haven't seen any conclusive evidence that it's readily audiable. ***
You do realise, don't you, that kernel streaming is *part* of WDM, so your statements are contradictory (I think i know what you are trying to say, though)
*** C'mon, if the PCI bus is so laggy that it's draining the buffer of your sound card (probably the slowest device on the bus), you'll be noticing some effects other than degraded sound. Probably crashing, as PIO requests from other devices on the southbridge queue up and pound the memory controller. ***
Well, what can I say? Your analysis is way too simplistic. Hint: measure the jitter output from your soundcard (using a variant of Julian Dunn's J-test). Measure it whilst the CPU is relatively idle, vs heavily utilized. Do you see a difference? Have any bits been lost in either case? What do you think accounts for the difference?
*** 44.1KHz being resampled to 48KHz WILL result in a degradation of sound? That's an interesting contention. ***
Try doing this. Take any source material in 44.1kHz, resample to 48kHz (using your favourite resampling algorithm). Then resample back to 44.1.
If the process was truly lossless (ie. no degradation in sound), you should get back exactly what you started with - bit for bit (or at least, close enough, accounting for quantization error).
Do you? Hint - have a look at behaviour for frequencies close to Nyquist.
The whole notion that resampling is somehow "transparent" or "lossless" is one of the great myths of digital audio.
*** Ever deal with enterprise java programming? :) ***
Not me, personally, as I've said a lot of my hands on stuff is well over twenty years ago. However, my team was responsible for doing some interesting stuff on services oriented architecture which i have presented in several conferences around the world (we do have a patent for the specific application though).
You do realise of course that "enterprise java programming" is an oxymoron? :-)
*** Yep, I miss DOS, too. ***
> Hey, if you quack like a duck ...Um, OK...
> You do realise, don't you, that kernel streaming is *part* of WDM
Of course. So what? waveOut resamples, kernel streaming doesn't. Same driver model, two different interfaces. Tack on DirectSound and the windows media player interfaces on top of that. Kernel streaming is the least damaging of all of them, and what I'm assuming most people using foobar2000 are using (that or ASIO.) So how is another process degrading the sound by (attempting) to open the audio device?
> Measure it whilst the CPU is relatively idle, vs heavily utilized. Do you see a difference? Have any bits been lost in either case?
Those tests are low on my list of priorities, but I'll run them when I get a chance. I've yet to hear the effects of jitter, however.
> Try doing this. Take any source material in 44.1kHz, resample to 48kHz (using your favourite resampling algorithm). Then resample back to 44.1.
Well now, that wasn't what you said in your previous post.
Of course upsampling mangles the original data, and up/down sampling is even worse. However, many on this board will contend that it sounds better when done properly. I could care less, 44.1KHz sounds fine to me.
> You do realise of course that "enterprise java programming" is an oxymoron? :-)
It is when poorly implemented, same as any other "enterprisey" language.
> Actually, no - don't confuse your background with mine. :-)
Actually I'm more accustomed to low level '64 programming. The SID was a thing of beauty...
/*Music is subjective. Sound is not.*/
*** So how is another process degrading the sound by (attempting) to open the audio device? ***I think I already gave you several examples, which I won't bother repeating.
*** Those tests are low on my list of priorities, but I'll run them when I get a chance. I've yet to hear the effects of jitter, however. ***
Hence my comment about your lack of experience. If you *had* run those tests, you would not made some of your comments ...
*** Well now, that wasn't what you said in your previous post. ***
Actually, it was. For reference, let me requote, word for word: "For example, not many people can immediately tell when 44.1 is being resampled to 48 and vice versa. But it *will* result in degradation of sound."
Of course, you can argue whether the degradation is audible or not. I suspect your ears are not well trained, so it may well be that you won't hear the artefacts.
If you are familiar with the sort of artefacts generated by resampling, you can train your ears to spot them, just like you can train yourself to distinguish different dithering algorithms. Search the web, there's at least one site offering "blind" comparisons.
*** However, many on this board will contend that it sounds better when done properly. ***
I'm not one of them.
*** It is when poorly implemented, same as any other "enterprisey" language. ***
Ahh, you completely missed my point! Never mind ...
:)
There are in fact some valid, and very specific, cases where it is *not* nonsense. It's easy to dismiss something when you don't fully understand the complexities of a modern operating system (and dare i say possibly not very well written? :-))
x
Christine,COuld one of these cases be when playing lossless files such as FLAC?
And could this account for some accounts of hearing a difference between .wavs and FLAC files?
At one stage, I was encountering crackling when playing back 192kHz 24 bit audio files compressed using Microsoft WMA Lossless.I kept thinking it must be a buffering problem, or a network latency issue (because these files were served off a NAS), then one day I realised the obvious ...
The CPU I was using was simply not powerful enough to decompress WMA Lossless at 192kHz fast enough.
I converted all the files to a less CPU intensive algorithm (Wavpack seemed to be the most CPU efficient, based on casual benchmarking) and suddenly everything was fine! :-)
Another reason for possible differences between WAV and lossless compressed files may be the extra CPU power required to do the decompression is injecting noise into the audio circuits (in the form of power supply fluctuations, or EMI).
Thanks.This makes my choice to rip everything to .wavs seem like a good one.
Since my cpu is pretty slow, it also seems like a good choice.
then you wouldn't concern yourself with this nonsense.
It is typical of respondents in this Forum that people pay no due regard to arguments or findings that ara posted, but respond spontaneously to what they hold are 'absolute' truths. There is nothing wrong with the Stereotimes article and no absolute statements about memory playback.
to be biased towards voodoo and snake-oil?"I prefer this subroutine because the sound is less recessed."
THIS IS A FORUM ON COMPUTER AUDIO; not computers and software.
Your response is EXACTLY what I said; pay no attention to the issue, just your own agenda
so are you concerned or not about dll's?!
http://www.audioasylum.com/forums/critics/messages/25394.htmlabout the so-called memory player which claims benefit from this.
As I said, i'm a bit out of date so I was just checking. Nothing much has changed.
think about it: if dll's are truly going to impact soundquality then why stop there?...
"So why the expressed concern about seeking and destroying all DLLs?"implies reference to third parties, in my book, but it might be ambiguous.
this board needs to update to modern forum software...
Do you mean the ones that have cute little pictures of the posters, and just juxtapose responses so they make absolutely no logical sense?Or make you read EVERY response to find the relation?
I've seen only one post that actually made this claim (and a number that have repeated it). I noticed that the original person did a number of other things at the same time they removed the unnecessary .dll files, so the claim has no merit, in my opinion.I believe it is just a simple misunderstanding by someone (and now a group of people) that doesn't understand what a .dll file is and how it is used. There are many such claims floating around, none of which have really been substantiated.
Until some of these claims are proven by a basic A/B comparison (preferably blind) in which no other parameters changed, they are about as useful as the claim I will make now:
My system has a lot less jitter when there is a full moon!!!
As we all know, DACs are sensitive to even small fluctuations in power supply, EMI etc.And as we know, logic transitions may create small power supply ripples or generate EMI.
Therefore it is theoretically possible that loading and unloading DLLs, or even the sequence in which DLLs are invoked, may have a possible impact on the sound. It is also possible that having too many loaded DLLs and not enough memory may cause additional paging activity which may affect the playback.
However, it is certainly a stretch to suggest that actively manipulating the status of DLLs in memory will make a big difference in the sound quality. At least any more than the zillions of other types of memory activity or logic transitions occuring in a computer.
Then again, Microsoft Windows is a highly complex and non orthogonal operating system - who knows maybe there is more here than it seems.
But I think you are playing a bit of devil's advocate. :)Let's keep in mind that the hard drive is probably being frequently accessed anyway while the music data is streamed off of it. And that these .dll files were probably loaded (if at all) before the user had a chance to hit the Play button. And that the memory, if it were that tight, would probably be swapped out at some point early in the process to make room for the music program and its buffers (causing, perhaps, a one time glitch, if any, not an ongoing problem that affects playback).
I say that such claims are akin to saying that the neighbor's electric toothbrush has an impact on your power. Certainly feasible, but at some point you have to draw the line. I am 100% certain that entertaining the thought that such a thing can be a problem will have a far greater psychnological impact on what you hear than the .dll files themselves. :)
... but I didn't want to dismiss it out of hand, however improbable it may sound. One thing I have learnt in my job is never rule out anything, no matter how improbable. One of my "successes" early on in my career was solving a system performance slowdown that was causing our customer to threaten ligitation - and the cause turned out to be something that everyone else had ruled out as being improbable but I was willing to entertain that it *might* be possible.As an example highlighting the complexity of Windows, one of our inmates discovered a few months ago that you can disable Windows Audio Service and still get sound, and hypothesized that this may be a way of bypassing kmixer.
Unfortunately, it turned out not to be true, after a search revealed the explanation by way of a blog from one of the Microsoft guys working on the audio service.
What actually happens is that disabling Windows audio service disables the user mode DLL that normally intercepts and services Windows multimedia calls, but then these calls then result in setupapi.dll being invoked as a fallback mechanism.
The reason for this redundancy is that setupapi.dll provides a set of services invoked by Windows during initial installation, and obviously there is support for audio even during installation.
setupapi.dll is never meant to be loaded in memory in normal operation as it consumes a fair amount of resources. So what our friend did is actually non-optimal and kmixer (which is a kernel service) is not being bypassed at all.
What has any of this to do with DLLs possibly affecting sound quality? Well, not much, but it does illustrate that the workings of Windows is a lot more complicated than most people think.
I wish I knew who started this dll rumor...do you realize how many different processes run at any given time during an active Windows session? To assume that dll's have an impact on the sound quality of music coming out is absurd, given the fact that there are many more intrusive processes being run by executed code, interdependencies, etc.
And this is what's wrong with Windows - bits thrown together.It is my experience that IT programs go wrong most when 'programers' assemble a lot of different 'library' codes without proper understanding or verification. And there are lots of them!
Call me old fashioned, but I believe, and demand in my work, understanding of what various processes do before accepting that they are 'faultless'.
This is where the EU is fining Microsoft so heavilly for failing to provide transparency in the Media Player side of things, making it difficult for others to provide 'fault free' competition.
Hokay, you've pushed a button here.Microsoft gets pilloried/fined/legislated against because they provide facilities such as browser and media player for free, thus hindering other organisations from screwing revenue out of the general public. These other organisations then lobby their politicos.
If the EU had their way, we would all have to buy a third party media player license as well as Windows. And a browser. And doubtless eventually a GUI.
Personally, I don't like Media Player, but I do appreciate that it's presence makes the alternatives considerably less expensive. Think back to what a WP suite used to cost before Office became the de-facto standard, and consider that the alternatives most worthy of consideration are either free or near as damn it.
Before OS/2 & WIndows, operating systems were far simpler, more expensive, and considerably more flaky. So please don't do the knee-jerk thing about Windows. And don't start wittering on about Apple, the last original idea they had was Lisa.
So you think that the crappy MP10 is better than the free fooobar and others. And you think that MP10 as a video player is acceptable compared to much better low cost alternatives.50 million lines of code is RIDICULUS for an operating system in terms of being able to fully comprehend what is going on.
Actually, if you bothered to read my post, I state that I don't like WMP. For audio I use Foobar, for video Powerdvd.How do you know there are 50 million lines of code in XP - have you counted 'em? Or do you just believe what you hear second hand.
Or perhaps mis-read.
Have you any idea of the overheads in providing out of the box support for the range of peripherals that XP handles?
Sorry, I don't usually get this aggressive - just don't like it when people mount a populist hobby horse. Badly.
here...
- http://www.businessweek.com/technology/content/apr2003/tc20030429_6540_tc047.htm (Open in New Window)
This only illustrates my point.1. It must be true 'cos it was in an up-market rag. Presumably written by some clueless hack with an eye for the sensational, and a qualification in English, media studies, or marketing.
2. If you actually READ the article it's about WinServer 2003, not XP.
BTW - please define what a line of code is in this context. Does it include comments, scripts, squiggly brackets, data definitions, picture definitions, help, etc. etc.. Real chaps talk about instructions.
AND, given the broad support for platforms, peripherals, and interfaces, how much of the code is actually relevent at any one time.
Tell you, a fully featured Linux distro makes XP look small. XP is even more scaleable. I have it running on a P133 laptop with 48MB memory & 2GB HD - including office. Not exactly fast, but it does run. Try and do this with KDE or Gnome.
that's the end of it... ;-)
Yet somehow WMP is half the size of Powerdvd 7.Bloatware is the name of the game nowadays, chiefly to make copying/txing as painfull as possible. All suppliers, not just Microsoft.
The MS corporate pack is even bundled so that it requires dual layer dvds for copying.
Look, I'm not saying that Microsoft is the best thing since sliced bread - I don't believe that they are any better, worse, smaller, or more bloated than the viable alternatives. I'm just trying to get people to think, rather than just paraphrasing populist media.
Or, to put it another way: "40 billion flies can't be wrong - eat shit".
... if you are familiar with fmak's posts, he has very fixed views on a lot of things and seldom change them no matter what other people say.I would agree that Microsoft does not necessarily produce code any more bloated than other developers. Though I could possibly suggest I have been less than impressed with some of their code.
Still, I do remember the days where you could comfortably fit a full Unix System V distribution on less than 20MB. And MS-DOS for many years can be installed on a single floppy.
When MSDOS first came out it had a slow take up in the UK 'cos people thought an OS that required 128KB ludicrous.
I remember the Apple II had an operating system (the Apple Monitor) that fits into 2K.By contrast, I rewrote the operating system for the Commodore 64 when I was a kid, borrowing a lot of the concepts from the Apple II, and it fits into 4K.
Here's a bit of interesting trivia: the current Apple MacOS is based on the Mach "micro-kernel" (there was quite a lot of research into distributed operating systems in the 80s, and micro-kernels came out of there) - but the Mach "micro-kernel" is far larger than the completely monolithic statically linked Unix V7 kernel :-)
A lot of the bloat is intentional though, because cheap memory allows you to have algorithms that are memory intensive but computationally cheap. Eg. my paper on Unix password decryption, rather than than doing the DES algorithm step by step, it's far easier to look up a 4MB precomputed table.
A lot of implementations these days do something similar, precompute, and use a lookup table. However, this causes large code.
instead they have bloated backwards compatible crap in there that creates a nightmare for interdependent processes and all the rest of the nonsense...
It's because of the "Microsoft way" - the majority of Microsoft development is done by very bright but recent university graduates. In other words, "mini Bill Gates"They have great productivity, and occasionally fantastic innovation, but it does mean Microsoft tends to have a "not invented here" syndrome and often the same mistakes are repeated again and again by each new team. Also the design tends to be long on "kruftiness" but sometimes short on the bigger architecture picture and longer term maintenance issues are sometimes not well thought through.
Take DLLs for example. Microsoft made the same mistake as Sun in not considering versioning - hence the issues we all face today. At least Sun was able to rectify their mistake - Microsoft took too long and the flawed design became entrenched.
I can understand "not invented here" because one believes one can do a better job, but jeez at least try and learn from your competitors' mistakes! :-)
that's why...
Inertia - changing policy in a large corporate is like turning a supertanker, so with Microsoft it must be like having several supertankers strapped together.Problem is the decision makers are too far away from the workface.
So you now agree with me?No, I do not have fixed views. I respect relevant views and learn from them, not comments that onlt computer codes and bits matter in audio.
Christine, if I have a view on band width and audio, it is because in 30 years of listening and measuring, limited band audio can sound nice, but never as good as wide band audio done right.
No I don't agree with you - it seems you filter every post to suite your requirements. Try reading all the words out loud (under your breath if this embarrasses you) it may help.How do you decide what is relevent?
What has longevity got to do with it - in fact, it could be argued that your training & premises are obsolete.
Certainly you should cultivate listening skills, open-mindedness, tolerance and flexibility. I can point you at suitable training material if you wish.
Just to show you how infantile your arguments are ...For the record, I have been "listening and measuring" for over 35 years. So you have 5 years of experience to catch up on.
Come and and talk to us then!
I made no arguments; if what I post is infantile, then you remarkds are stupid.
Christine,Fmak knows all. Remember this.
40 years in my case. Course this just means we are all hf deaf....
This post is made possible by the generous support of people like you and our sponsors: