addicted to linux

Status
You're currently viewing only IMarshal's posts. Click here to go back to viewing the entire thread.
Not open for further replies.

IMarshal

Ars Tribunus Militum
1,956
treatment:<BR><P>So instead of saying "MS has a monopoly, so specs are restricted", you're saying "hardware support for certain devices is so difficult that even MS can't do it right". Make up your mind, man.<BR><P>Wasn't there a patch for USB on Win95, BTW? USBSupp.exe, or some such thing? As for NT4, I'm not sure how easy it would have been to add USB support to a non-PnP OS. In both cases, though, the idea of encouraging upgrades probably weighed more than technical factors.<BR><P>BTW, CD-R support is 100% provided by the burning software, even on Windows. Please explain how Microsoft's monopoly is impeding CD-R support on Linux.
 

IMarshal

Ars Tribunus Militum
1,956
treatment:<BR><P>I think I'm reading your posts just fine. You have such an amazing mishmash of anti-Microsoft conspiracy theories that defy the facts.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>Microsoft made manufacturers conform to Win9x-compliance.<HR></BLOCKQUOTE><BR>Well, Microsoft and Intel established PnP guidelines for the industry, and Microsoft said "if you don't write Win9x PnP drivers your hardware won't work with Win9x". Aside from WinModems and the like, I don't see how this is monopolistic. (And even WinModems just need drivers to work elsewhere...) Are you suggesting that an absence of PnP guidelines would have been better?<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>The fact that even Microsoft can't make NT work with Win9x-compliant hardware/software only makes it more obvious that the MS's Win9x-compliance/monopoly-practice is bad even for Microsoft themselves<HR></BLOCKQUOTE><BR>The fact that NT5 has good PnP / USB support belies your claim. I don't like the fact that NT4 doesn't support USB, but like I said, it was more a marketing decision than a technical one.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>I have a perfectly reliable usb-equipped/enabled Win95-computer. To be blunt, these Win95-computers are Win95-C versions and have other usb-equipments working fine with it, except the new equipments such as Handspring<HR></BLOCKQUOTE><BR>First of all, they may simply have that warning because IIRC no version of Win95 shipped with built-in USB support. Have you actually tried your hardware with your version of Win95?<BR><BR>Secondly, if you look through the MS KB, you'll see that a lot of USB problems are fixed in Win98. It's possible that Win95's USB support can't handle a certain USB feature that your hardware uses.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>Why...? Why...? Why...?<HR></BLOCKQUOTE><BR>Very simple. MS wants to make money just like anyone else. They want to have compelling features to make you upgrade your OS. If you were them, would you repackage every NT5 feature into NT4 at no additional cost? Would you have released Win98 for free? At some point you have to draw the line between a free service pack (which should have no new features, just bugfixes, right?) and an upgrade.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>Microsoft publishes DirectX technologies that are usually incorporated into media-software such as CD-R software<HR></BLOCKQUOTE><BR>LOL! Excuse me?!? Name one CD-R package that requires DirectX in order to write CD's. (Note, just because an app might use it to give you an animated paperclip while they burn CD's doesn't mean it's "necessary".)<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>DirectX is a proprietary Microsoft API for media(sight,sound,etc) and I believe most, if not all, CDR software for the Win9x-platform must conform to it for better working-relationship with Win9x-platform, in conjunction with using MS Dev-tools such as VC++ that uses MFC. This is an extension of monopolistic-practice that even MS itself is suffering from. <HR></BLOCKQUOTE><BR>treatment, you are severely confused. DirectX has nothing to do with SCSI, IDE or CD-R. Are you thinking of ASPI? Do you know what the 'A' in ASPI means? And what do MS Dev tools have to do with _anything_? Do they force you to use DirectX? Do they force you to use MFC? Do you have to use MS dev tools to writer apps for Windows?<BR><P>Sheesh, man. You're smarter than this.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>Even Alex St.John (directx creator) doesn't make apologies for Microsoft's practices.<HR></BLOCKQUOTE><BR>LOL, please provide a link to Alex St. John mentioning ASPI, CD-R's or USB as part of the grand hardware monopolizing scheme. (If anything, he'll talk about how Microsoft wanted to see developers coding games for Windows. For shame, Microsoft!)
 

IMarshal

Ars Tribunus Militum
1,956
treatment:<BR><P>Forgive me when I say that you are so amazingly confused that you don't even seem to know what you're arguing about.<BR><P>This conversation went like this:<BR><ul><BR><LI>Someone: my CD-R works in Windows, sucks to use in Linux<BR><LI>treatment: that's because MS has a monopoly, closed specs, bla bla.<BR><LI>Me: what does MS have to do with CD-R support?<BR><LI>treatment: DirectX, Alex St. John, USB, bla bla.<BR></ul><BR>It would be nice if you could clearly state what it is that you're trying to argue about Microsoft and CD-R's.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>... Links to Adaptec stuff<HR></BLOCKQUOTE><BR>So they mention DirectShow 6.0, a very small component of DirectX that provides some video services. WTF does this have to do with USB, 1394 or CD-R? Every platform has its own multimedia layers, and the Windows software that is shipped with 1394 hardware uses the Windows multimedia layer. Shocking, huh?<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>Nowhere did I even mentioned ASPI, SCSI, or IDE<HR></BLOCKQUOTE><BR>You're right, you said "DirectX is a proprietary Microsoft API for media(sight,sound,etc) and I believe most, if not all, CDR software for the Win9x-platform must conform to it". I guess my humble attempt to educate you as to what's important for CD-R support failed.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>Sonic-Foundry used to have a directx plug-in for noise-reduction, too.<HR></BLOCKQUOTE><BR>Sonic Foundry writes CD-R's? Wow, I'm sure ACID will be happy to hear that.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>Where is NT-5 right now?<HR></BLOCKQUOTE><BR>On a lot of people's machine, including one of mine, and very close to RTM. You'll have to do better than that.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>Why did MS stop DirectX on NT-4 to DX-3 and not upgrade to the latest DX-versions of those days? It's not marketing. It was a technical issue that they could not resolve.<HR></BLOCKQUOTE><BR>treatment, you can foam at the mouth all you want. You've demonstrated in this thread that you don't have a clue about DirectX, or Windows software. Please don't embarrass yourself further. If there were showstopping technical issues then how do you explain DirectX on W2K?<BR><P>The fact is that Microsoft originally intended to release NT5 in early 1998, and USB / FAT32 / DirectX were intended as upgrade incentives. Afterwards, even though NT5 was delayed and delayed, Microsoft had already committed to adding no more features in service packs after SP3. Try to think - how hard do you think it would have been to have slipped a FAT32 filesystem driver into NT4SP4? Consider why they didn't do it, and extrapolate to something a bit harder, like USB.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>DirectX, bla bla.<HR></BLOCKQUOTE><BR>Let me ask you this: what is the relevance of DirectX to this thread, now that we've established that you don't need DirectX to burn a CD?<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>poor quality and incompatibilities of these manufacturers' drivers i.e. sblive and tnt.<HR></BLOCKQUOTE><BR>Welcome to the wonderful world of IHV drivers. If you think the Windows driver scene is bad, wait until you see these guys try to keep track of Linux kernel versions and whatnow. And until Linux becomes more popular, we'll see how many resources are invested in these drivers. Are you still wondering why thee drivers have been open sourced?
 

IMarshal

Ars Tribunus Militum
1,956
treatment:<P>There seems to be a fundamental disconnect between what I'm talking about and what you're arguing. I'm trying to understand where you're coming from, but it's difficult. My Slashdot reading experience is coming in handy, so at least your paranoia isn't foreign to me, although your lack of logic is still rather disquieting.<P>This conversation started because you stated that CD-R burning is difficult on Linux because of the Microsoft "monopoly" and their control over hardware specs. However, you have yet to explain how CD-R specs are somehow proprietary, or closed, and what information isn't available to Linux coders. So, here's a question: how does Microsoft affect the Linux CD-R burning experience?<P>Now, DirectX entered the conversation when you stated that "Microsoft publishes DirectX technologies that are usually incorporated into media-software such as CD-R software". Aside from being absurdly off-topic, this is simply wrong. You have yet to name a CD-R package that uses DirectX at all, much less in any fundamental way. Here's another question: what does DirectX have to do with burning CD's on Win9x or any other platform?<P>On a more general level, you appear to be using DirectX as an example of Microsoft imposing proprietary interfaces on hardware manufacturers and making it more difficult for IHV's to support other platforms. For someone who claims to have programmed something, this is an amazing assertion. The fact is that there is nothing that DirectX imposes on hardware design; you write a DirectX driver for your hardware just like you write an OpenGL driver or a Glide driver, or an X-Server or a GDI driver. It's all the same principle: provide interfaces that allow performant access to hardware in a generic manner. I fail to see how this comes at the expense of other platforms; after all, if the marketshare for OS Y is there, the hardware will come with drivers for OS Y. Or do you really think that DirectX support in a video card means that the same video card can't be used in X?<P>WinG is completely unrelated to DirectX, BTW. WinG is a fast bitmap modification API, while DirectX provides a frame buffer, 3D services, sound, networking, video, etc. And DirectDraw didn't evolve from WinG; their interfaces are completely different.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>NT can't really work with DirectX because of NT's HAL.<HR></BLOCKQUOTE><P>So does this mean that NT can't burn CD's? :)<P>More seriously, I'm afraid you're wrong. NT4SP3 supports DirectX 3.0, and NT5 supports DirectX 7.0. Both have fully functional Hardware Abstraction Layers (yep, that's what HAL stands for). And NT4 is very similar to NT5 internally, so your argument that "NT4 doesn't have these features so there must have been a technical impossibility" is proven wrong by the sheer existence of NT5 and its feature set.<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>NT-5 is on alot of beta-testers' computers. It is not sold on retail and is not supported by MS, unless you are part of the beta-program. So you're argument on NT-5 being on alot of people's computer doesn't stand at all.<HR></BLOCKQUOTE><P>Irrelevant. The mere fact that NT5 exists and supports all the things that you said NT was incapable of supporting means that your claims of "fundamental technical problems" were wrong. If Microsoft had wanted to add USB and DirectX to NT4, they could have. Easily? Well, no; it would have required more than a one-line code change, sure. And NT Service Packs do not add features, especially big features that require significant kernel changes. That's why leaving them as NT5 features made sense even beyond the marketing strategies.<P>About Linux drivers from IHV's: you don't have to believe me, just wait and see. I predict that there will be fundamental problems and incompatibilities with driver versions and kernel versions. Don't bother arguing with me here; you've already demonstrated you don't have a clue about software development. Time will prove me right or wrong.<P>The rest of your message directed at me is pure insult, so I'll ignore it. I'll say one thing, though: the way you accuse me of being in a "Microsoft bubble" while making the absurd claims that you make without evidence merely indicates that you have fallen for the Slashdot "open source, closed minds" mindset. Please take a deep breath and drop the group-think. You too are an individual.<P>Edit:<BR>One thing I forgot to comment on:<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>I have already stated to you in another thread why DirectX and any other Microsoft APIs are not compatible with GPL that governs Linux.<HR></BLOCKQUOTE><BR>It's amazing how you never learn a thing. Do you read what I write? In that thread I pointed out that you can't place an API or set of interfaces under the GPL; it takes real code to do that. (Of course, you probably never read that, or understood it.)<P>As Wine, Willow, Wind/U and other API-emulators have demonstrated, cloning Microsoft's API's on other platforms is as feasible as anything else. There's no reason why you can't write a GPL'd DirectX or Win32 app, even on Linux, as long as your OS provides an implementation of those interfaces for you. Luckily, both Windows and Wine provide implementations of Win32, so one can run most Win32 code on both Windows and Linux.<P>You _do_ know the difference between interface and implementation, don't you?<P>[This message has been edited by IMarshal (edited December 07, 1999).]
 

IMarshal

Ars Tribunus Militum
1,956
This comversation really is too funny. It's like arguing with Eliza's twin brother, the advo-kiddie.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>I commented on how DirectX is part of this "simplification" by stating that DirectX is incorporated on most CD-R software; not on CD-R standard itself. See the difference?<HR></BLOCKQUOTE><P>The problem is that your statement is false. CD-R software does not need to use DirectX for anything. There might be some package or other than uses it to provide eye or ear candy of some sort, but I'm not aware of any that do. What evidence do you have for DirectX incorporation into CD-R software?<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>I have only shown E_M the reason why most software including CD-R software are much more easier and available on the Win9x-platform. Read the posts again. You are still trying to trip me up and it's not working. You are the one getting confused.<HR></BLOCKQUOTE><P>You're right; you trip yourself up with no help from me. CD-R software is easier and available on Win9x because of DirectX? That's a interesting theory. Do you also think that there are more Zip drive utilities on Win9x because of DirectX? Are you aware of the fact that virtually all 9x CD-R software works on DirectX-challenged NT as well?<P>(BTW, isn't it a lot more simple to think that CD-R software is more plentiful on Windows than Linux because Windows users are more plentiful than Linux users? Or are you claiming that there's something about Windows that makes software run better than on Linux? Or maybe the hardware works better? That's not what I think - it's what you seem to be saying.)<P> <BLOCKQUOTE><font size="-1">quote:</font><HR><BR>>You have yet to name a CD-R package that uses DirectX at all,<BR>>much less in any fundamental way.<P>Since you are so thoroughly confused by your own bias, I suggest you re-read my assertion again. If I have the source-specs of these particular software, maybe I can really tell you where exactly DirectX-calls are being made by the oem-software.<HR></BLOCKQUOTE><P>You're tripping over yourself again. Any competent developer or knowledgable admin knows how to tell which apps call into which DLL's. Obviously you are neither.<P>What's funny is that you make the claim that "DirectX is incorporated on most CD-R software", but when asked to provide evidence, you say "If I have the source-specs of these particular software, maybe I can really tell you where exactly DirectX-calls are being made".<P>In other words, you're talking out of your ass. Just like those guys who rant about hidden Microsoft API's, but when asked to produce one, say "well, they're secret, so of course I cann't give you an example."<P>Why don't you just salvage a little credibility and admit that DirectX has nothing to do with CD-R software?<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>I gave you an answer about NT's HAL and DirectX not being compatible with each other. Microsoft itself published this reason when DirectX-4 and DX-5 was released on Win9x and not on NT-4.<HR></BLOCKQUOTE><P>If you're genuinely interested in this discussion, open a new thread. And while you're at it, provide a link to Microsoft's article on DirectX being incompatible with a HAL.<P>(BTW, DirectX 4? When was that released?)<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>WinG was the name Alex St.John called DirectX before Microsoft standardized on the term DirectX. WinG/DirectX was originally purposed to handle only porting of DOS-games and video-cards. Microsoft "extended" this original purpose to encompass all Win9x media software-interface.<HR></BLOCKQUOTE><P>Unfortunately, you're wrong. Here's a quote from http://msdn.microsoft.com/library/techart/msdn_roadmap.htm:<BR> <BLOCKQUOTE><font size="-1">quote:</font><HR>WinG is a graphics technology that was introduced on the Windows 3.1 platform to allow games developers to use some DOS graphics techniques under Windows. Essentially, WinG allows you to use GDI to draw on a device-independent bitmap (DIB). WinG functionality is now built into Win32 through the CreateDIBSection function.<HR></BLOCKQUOTE><P>WinG may or may not have been created by the Saint (got a link?), but it was simply a bitmap twiddling API used in Windows 3.1. DirectX is much more; even 1.0 was much more. To say that DirectX evolved from WinG is like saying that the web evolved from FTP.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>Do you remember SP-2 debacle? Do you remember SP-3, 4, 5, 6, 6a functionalities for NT-4? Isn't Winsock-2 on the kernel-level of NT-4?<HR></BLOCKQUOTE><P>Like I said earlier in this thread, as of SP3, no more features were added via Service Pack in NT. Since you don't know how to read, I guess you missed that.<P>You can bluster all you want, but that was the decision that was made. SP2 and 3 contained quite a few new features, but a line was drawn in 1997. Go ahead and find me a feature that was added in SP4 or beyond. You won't find anything significant - it's all bug fixes or security issues. And yes, clueless wonder, Winsock 2 is in the NT4 kernel. It has been there since NT4 RTM or SP1 (can't remember - I think it was RTM).<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>You keep trying to implement the same flawed software-development model that the OSS-model replaces on an OpenSource project like linux.<HR></BLOCKQUOTE><P>LOL! Do you honestly think that open source represents a revolution in software development? Do you really believe that ESR's laws trump Brooks'? I guess if you read enough Slashdot, you might end up believing that...<P>I will admit one thing that open source has achieved: it has invented the most efficient known mechanism for cloning and reverse engineering existing programs and architectures. But that's about it.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR><BR>>you can't place an API or set of interfaces under the GPL; it<BR>>takes real code to do that.<P>It is you who do not understand what and how GPL works<HR></BLOCKQUOTE><P>You're so simple. All you can think of is the open / closed dichotomy. Of course the GPL is a landmine! Why the hell else would Sun, Apple, Novell and everyone else be producing their own licenses?<P>The point is that an API is not code; it's a contract, a declaration of intentions, a promise. You can't GPL an API, only a specific implementation of an API.<P>And BTW, you happen to be talking to someone who publishes software under the GPL in his spare time. My understanding of the GPL goes beyond your sycophantic advocacy.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>There's already alot of tools, such as GTK, FreeQT, and even Tcl/TK, that already provides DirectX-like functionalities. But if you want to GPL the full DirectX-APIs, you need to convince Microsoft for us. DirectX is not needed in linux nor in XFree.<HR></BLOCKQUOTE><P>You _really_ don't understand DirectX at all if you think GTK, QT and Tcl are in some way analogous. I think it's time to stop talking about DirectX; you're as bad as RiscRocket and SMP.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>I can only speak of WINE and it does not contain any MS API at all.<HR></BLOCKQUOTE><P>And now you don't know even what an API is. Good heavens, man, you need some educating.<P>treatment - if I may be so bold: how old are you? What is your background in Computer Science? Am I wasting my time with you?
 

IMarshal

Ars Tribunus Militum
1,956
I was about to reply to treatment's latest rant when it occurred to me that there were far too many things I could do in the next twenty minutes that I would find far more rewarding.<P>All I can say is that if a senior CS major:<P>a) doesn't know how to figure out which DLL's are being loaded by a Windows program,<P>b) doesn't know the difference between an interface and an implementation,<P>c) thinks that proof by assertion is sufficient to argue a point,<P>d) thinks that open source software is a phenomenon invented by the 90's generation, <P>e) believes that the fundamental laws of software development are trumped by open source, and<P>f) believes that everything Microsoft does is evil incarnate,<P>then I'm not going to waste my time trying to teach him differently. treatment, the day is long and the web is vast. Please broaden your scopes and educate yourself.<P>[This message has been edited by IMarshal (edited December 09, 1999).]
 

IMarshal

Ars Tribunus Militum
1,956
treatment:<P>The problem with you is that you're not interested in the truth at all: you're just agenda, agenda, agenda. You're not here to learn, or to inform others; you're here to spread gospel and what your tribe calls inverse FUD. Why should I waste my time honestly answering your questions? I simply don't think there's anyway to get through the levels of paranoia and prejudice. And it's not my job to educate you anyway.<P>You expect me to reveal my identity by disclosing which OSS programs I've written? Please. Anonymity is something that I value.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>the DVD model is almost exactly the same as CD-R/CD-RW but with more functionalities<HR></BLOCKQUOTE><P>This is another example of how you don't know what the hell you're talking about when it comes to hardware or software in general. There are _worlds_ of difference between the DVD playback interface described above and what a CD-R driver interface looks like. LOL!<P><strong>ordermaster</strong>, since you seem a bit more rational:<P>1) Why do you think that if Microsoft makes it easy to write Windows drivers, IHV's will be less likely to support other OS's? Wouldn't it free up resources to write other drivers?<P>2) Would you have Microsoft make it more difficult to write Windows drivers, to be fair to Linux users?<P>3) Why can't Linux provide a multimedia API as good as DirectX that will facilitate IHV driver development?<P>4) What exactly is the problem with DirectX anyway? Every OS has its own specific API and driver model, and most OS's have their own multimedia API. Are GameSprockets on the Macintosh somehow evil, like DirectX appears to be? Are the BeOS media and driver API's despicable because they're not available on other OS's?<P>I think the hatred for all things Microsoft is getting a bit out of hand here.<P>[This message has been edited by IMarshal (edited December 10, 1999).]
 

IMarshal

Ars Tribunus Militum
1,956
I can't reply in length because I have a plane to catch. But I think anyone who could possibly still be interested in this thread knows or at least suspects which drugs treatment is on.<P>What concerns me most, treatment, is your tendency to either misinterpret or downright lie when paraphrasing. That indicates either <strong>dishonesty</strong> or <strong>retardation</strong>. Please produce the quote where I said what you claim I said above about API's and GTK. Or admit that you were wrong to put words in my mouth.<P>Like I said earlier, if you had genuine questions that idicated curiosity, I'd be happy to answer them as best I could. If you had genuine objections, I might rephrase my thinking because you were right. But you're just agenda, you debate dishonestly and your technical knowledge is miniscule at best. You remind me of those Amiga advocates who used to get all their clues from the amazingly biased Amiga journals and magazines, accepting them as gospel truth. Proof by agreement. Groupthink.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>Your "anonymity" excuse is pathetic. I'm not asking your identity, I'm asking the GPL-products<HR></BLOCKQUOTE><P>Note that I didn't say "contributed to". I said "written", as in "started and wrote the lion's share of". Big difference. I'm still very visible in those projects and it would be impossible to miss me.<P>Anyway, I think the funniest thing by far of what you said is this:<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>So, by all means, continue making apologies for MS in how equipments are handled easier in Win9x platform.<HR></BLOCKQUOTE><P>That right! Dagnabbit! Shame on Microsoft for providing a workable standard driver model. Shame on them for working closely with IHV's to produce reasonably good drivers for Windows. Shame on them for providing a platform people use and develop for.<P>Ordermaster, I'll respond to your most civil opinions when I get back.<P>[This message has been edited by IMarshal (edited December 10, 1999).]
 

IMarshal

Ars Tribunus Militum
1,956
treatment, the only thing you've proven is your own inability to remain on topic. And don't even get me started on your ignorance of basic software concepts.<P>Some notes:<P>GTK, QT and TCL are mostly windowing libraries that provide an API for windowing apps. DirectX is a low-level driver API that provides several distinct multimedia services. The API's you mention are analogous to MFC or to the GDI / messaging subset of Win32. DirectX is a different animal entirely. Its closest relatives on Linux would be svgalib, some small parts of X-Servers, OpenGL and whatever API's Linux games use for sound. The truth is that Linux doesn't have an all-in-one equivalent to DirectX.<P>But beyond this, it's really not clear what you're arguing about when you say that I haven't "differentiated DirectX and GTK". I don't have to differentiate them; they differentiate themselves: they're very different API's for very different purposes. Is this an admission of cluelessness on your part?<P>Now, about GPL's and API's: the current implementation of GTK is GPL'd, yes. But I or anyone could write a library implementing GTK's interfaces that wasn't GPL'd. Understand? My closed source version of GTK would allow all GTK apps to compile, and maybe even provide binary compatibility. So it's not the API itself that's GPL'd: it's the specific code that implements the API that is released under one license or another.<P>Concerning USB in various MS operating systems, the fact is that I agree with you that it would be nice if NT4 supported USB, and it would be nice if Win95 provided the same level of support that Win98 does. It would also be nice if Windows 3.1 supported USB, and it would be nice if Windows 2000 were a free upgrade for all Windows users. It would be nice if Linux had better desktop apps. It would be nice if there were no wars in the world.<P>The fact of the matter is that no software is perfect, and Microsoft, like any other company, needs to create sources of revenue for itself. It can't spend man-years providing free features for legacy OS's when it has already provided those features in newer ones. They do a decent job of providing free bugfixes, but one can understand why they might reach the point at which they say "we can't continue to maintain this code".<P>BTW, my mention of Win2K is to contradict your assertion that fundamental technical problems impeded the implementation of DirectX and USB support in NT4. The W2K kernel and HAL are pretty similar to the equivalents in NT4.<P>AirFabio, your post deserves no real reply.<P><strong>ordermaster</strong>:<P>There's nothing except effort that stops anyone from porting MS API's to Linux. The Wine project is a good example of this. If you mean that only Microsoft can take the Microsoft implementations of MFC and DirectX and port them to other OS's, then yes, that's obvious, but you'd probably have to do a close-to-full rewrite to move Linux specific libraries to Windows anyway.<P>The problem with the open-is-always-better argument is that it really comes down to an issue of practicality. Not all 'open' toolkits have been ported to all OS's, so crossplatform is more of a theoretical asset than a real one. There are commercial toolkits that do a much better job of providing cross-platform libraries than any of the free kits, anyway.<P>The sad reality is that the vast majority of developers write code to the API's that provide them with the greatest possible audience for their products. They don't really care that much about openness or closedness, because for the lifetime of a single product this sort of issue is more or less irrelevant.
 

IMarshal

Ars Tribunus Militum
1,956
ordermaster:<P>I'm not really arguing with you, just reflecting on the open / closed paradigm that you mentioned earlier. I'm not sure that DirectX could have been designed to be more portable than it is, considering that:<BR><ul><BR><LI>DirectX is a driver-level API that provides many different services. Not all OS's have the same driver interfaces or deal with audio and video hardware in the same way. Not all OS's have working COM implementations to provide interface versioning.<BR><LI>A user mode DirectX wrapper could be written for any OS, but performance would suffer when compared to native solutions. OS vendors would implement DirectX themselves, and who would bring in another vendor's driver API?<BR></ul><P>So perhaps we could have had a platform independent DirectX, but it would have been something else, and not DirectX. Furthermore, OpenGL is a bad example because when DirectX was created it practically didn't exist for PC's, in the sense that no hardware vendor provided enough 3D features and no hardware vendor wrote OpenGL drivers for any video card. It was only later that OpenGL became usable for PC's, and by that time DirectX was already at version 3.0 or so. Microsoft might have used OpenGL instead of Direct3D, but they would have ended up with a Frankenstein-like API for multimedia.<P>I'm not saying that Microsoft didn't create their own API with the objective of engendering software that would only run on Windows; it's clear that this was one of the objetives. But there were other factors too, including the most important one: Windows lacked multimedia services, so an API had to be created. Microsoft, like many other companies, tends to distrust NIH technologies. Was it a good decision for consumers? It's hard to say. Was it a good decision for the company? Definitely.<P>treatment:<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>As the DART sample above directly implies, you'll need a DirectX plug-in to enhance the audio-recording. I've used the newer DVD spec outlined by Microsoft since DVD dramatically shows how DirectX becomes more thoroughly involved in the recording of audio, video, and data, and that it will only involve a small part of oem/ihv participation.<HR></BLOCKQUOTE><P>Who has denied that ISV's use DirectX to provide multimedia services? That's the whole idea of DirectX. However:<P><ul><LI>DVD has nothing to do with CD-R<BR><LI>CD-R burning itself has nothing to do with DirectX.</ul><P>Now, there may be software that uses DirectX for one reason or another, as in the example you mention. On Windows, you have two choices to use if you want to deal with audio: DirectSound or the old MCI Wave API. They chose the better one. But when the filtered audio is burned to a CD, DirectX does not intervene; unfortunately, every CD-R package on Windows has to implement its own CD-R support.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>As far as your claim that you can have a closed-source GTK-implementation invalidates that circular-logic because if you use GTK, you must agree to open up your source as required by the GPL.<HR></BLOCKQUOTE><P>Here's where your mistake lies. My closed source GTK doesn't use GTK at all; it just implements all the functions declared in the public GTK headers, or exported by the GTK shared libs. It's a clean-room implementation, so it wasn't infected by the GPL. I will repeat the important point for you: <strong>you cannot GPL an API, just an implementation of an API</strong>.<P> <BLOCKQUOTE><font size="-1">quote:</font><HR>You claimed that GTK and TK are not analogous to DirectX and showed another generic PR explanation.<HR></BLOCKQUOTE><P>treatment, I'm trying to be civil with you. But you're acting like an idiot and there's no way around that. Whenever I say something you don't like, you call it "PR". Where are your facts? All you can quote is stuff that has nothing to do with the topic at hand. Just because http://www.egroups.com/group/tkgs-list/21.html says that a Windows port of GTK uses DirectX to draw doesn't mean that the two API's perform the same function. By your logic, Gnome and svgalib are the same, because Gnome might use svgalib to draw widgets on the screen.<P>The fact that you haven't backed down on your assertion that "most, if not all, CDR software for the Win9x-platform must conform to [DirectX]" simply means that you don't know anything about CD-R software or Win9x or DirectX.<P>I'm glad that you're done with the issue. Perhaps you can find someone more clueful than you to argue your points?
 
Status
You're currently viewing only IMarshal's posts. Click here to go back to viewing the entire thread.
Not open for further replies.