locked
DX8VB.DLL, DX7VB.DLL, VB6 and Vista Compatibility RRS feed

  • Question

  • (split from http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1221168 to make a new question)

    It is interesting that you say that because I am testing a VB6 app that was working fine on XP and below but now fails on Vista when it tries to create a DirectX8 object, specifically

    Set oDX = new DirectX8

    throws Error 429, ActiveX failed to create component.

    Running in XP SP2 compatibility mode does not work either.

    I would be really grateful if anyone has any ideas on this.  I also tried running the latest DX9 redistributable because I heard that was providing backward compatibility, but to no avail.

    Thanks.

    Tuesday, February 13, 2007 5:56 PM

Answers

All replies

  • I have read on this forum and elsewhere that Vista supports earlier versions of DirectX through the use of DirectX9.  Yet, I have a DirectX8 application that works perfectly well on XP but fails on Vista.  Specifically:

    set oDX = new DirectX8

    returns Error 429 ActiveX failed to create component.

    The reason this happens is because dx8vb.dll is missing on Vista RTM.  When I copy this file onto my system and register it, my application works.  So my questions:

    1. Is dx8vb.dll missing by design, or will it be added in later Vista DX distributions?
    2. I need to fix my application for Vista so is it safe to redistribute just this dll? (I tried running the DX8.1 runtime distribution on Vista to reinstate this file but without success.  The installation appears to perform a version check and then report success without actually doing anything.)

    Incidentally, I am not alone in experiencing this problem:
    http://toca.game-editing.net/forum/viewtopic.php?t=785&sid=e86d82f7f792a21560de765ce70dd023
    http://www.bhmotorsports.com/board/viewtopic.php?t=41474&sid=56
    http://amabilis.com/eve/forums/a/tpc/f/2046019974/m/99610713631
    http://www.truevision3d.com/phpBB2/viewtopic.php?t=14624

    Thanks.

    Thursday, February 15, 2007 1:11 PM
  • Have you ever had to install this file on a clean windows installation before? I'm wondering how the file normally gets onto peoples machines. Since its a DirectX 8 file its not something that DirectX 9.0 will install and it seems unlikely that it would come with the OS since DirectX 8 totally predates windows XP. (Let me correct myself there since DirectX 8.1 shipped with Windows XP)
    Tuesday, February 20, 2007 8:00 PM
  • After some research I've come to the conclusion that this file shipped with XP since it came in the box with DX8. The DX9 installer doesn't include this file so there is no currently supported way to get the file on the machine.

    Hopefully someone in the Vista team can let us know if this file was an official omission or not.

    Wednesday, February 21, 2007 12:48 AM

  • I'm currently searching for a solution to the exact same problem.  I've tested both with DirectX7 and DirectX8, called from a VB6 app under Windows Vista, and in both cases, the initialisation of the main DX object (set in the same way as in Hightower's post above) comes up with an error #429.

    The error message seems to suggest that an OCX or DLL might be missing, but as it doesn't specify which one, it's not too helpful.

    If there's anyone who has or can find a solution to this (perhaps a Microsoft employee or another developer who's already come across the problem), it would would be hugely appreciated.

    Thanks,
       Ryan

    Thursday, February 22, 2007 4:11 PM
  • Check this out http://forums.microsoft.com/msdn/showpost.aspx?postid=1231805

    Its looking like the DirectX activeX control is not on vista by default as it was in XP. We are currently trying to work out if DX9 is supposed to install this or not but either way its not there in Vista and since tis part of the DX redist you are not technically supposed to install it yourself. The reports claim that the DX8 redist isn't installing it either.

    Thursday, February 22, 2007 5:41 PM
  • Just to confirm, I have never needed to distribute dx8vb.dll before. My installer only runs the DirectX8.1 redistributable if it detects earlier versions of DirectX.

    If I run DXDiag on a clean Windows XP SP2 then version 9.0c of DirectX gives dx8vb.dll as one of its files (as well as dx7vb.dll). So I can only assume that the file was there as part of DirectX9 but has been removed for Vista.

    I could redistribute dx8vb.dll to fix my application but as you say this is unsupported. But running DirectX8.1 or the latest DirectX9 runtime distributions does not fix the problem either.

    I am in the middle of remastering my CD-ROM titles for Vista and need to know what to do ASAP.

    Friday, February 23, 2007 12:46 PM
  • I am awaiting a reply from the DirectX team on this one.... your patience is appreciated
    Friday, February 23, 2007 5:36 PM
  • I am awaiting a reply from the DirectX team - their response time to MVPs varies.

    If its very urgent to your business you might want to call Microsoft support and escalate the issue yourself. You may have to pay but since you have a business issue that may be worth doing

    I have had someone confirm for me that if you look in the redist CABs for DX9 these files are there so my guess is that this *should* be supported by running a DX9 install even if they have chosen not to include them in the OS.

    This has also been raised in this thread http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1223939 

    (oh and I'm moving you back to the DirectX forums, sorry that the Vista people were not more helpful)

    Friday, February 23, 2007 5:42 PM
  • I had the same problem.

    I was able to resolve it by copying DX8VB.DLL from an XP system into the Windows\System folder of Vista and registering it as a COM object (you know, the whole regsvr32 thing...)

    Microsoft mistakenly forgot to include that DLL in the Vista installation, so you need to include it in your own games setup.

    Hope that helps.

    David

    Friday, February 23, 2007 9:05 PM
  • I was able to resolve it by copying DX8VB.DLL from an XP system into the Windows\System folder of Vista and registering it as a COM object (you know, the whole regsvr32 thing...)

    Which is in violation of the DirectX EULA - though I have no idea about how this is enforced.

    Microsoft mistakenly forgot to include that DLL in the Vista installation, so you need to include it in your own games setup.

    For now we have no confirmation of mistake or not - it could be that there is a compatibility/security issue and it was omitted on purpose.

    However your work around is something people can try, just be aware that Microsoft will probably not support you if you have any issues (though how much support you get for a dx8 dll is probably a valid point here) using it.

    Friday, February 23, 2007 9:44 PM
  • I'm not sure how it could be a violation. The file is included as part of the Direct8 and 9 redistributable. It's no different than installing the file via the directx installation package. The difference being that you can't install either DX8 or 9 onto Vista to get that file into the system. I'd be more than happy to stick to the regular system of installing an DirectX redistributable package onto the system and putting that file in place, unfortunately, that no longer works.

    Microsoft claims they fully support VB6 on Vista. They also claim they fully support DirectX8 on vista.. so.. if they fully support both, then that file should have been included. So I consider it a mistake.. it had to have been an oversight. There's simply no way they could have left it out on purpose requiring a huge multitude of commercial games, medical applications, physics simulations, and myriad of other VB6 created programs to be rewritten in VB.Net and using DX9..which in of itself requires a huge rewrite of code. Not to mention having to deal with the performance hit and unsecured executable.

    VB6 can't use DX9 because it was designed for VB.net (a mistake too but that's personal opinion). So, Microsoft is either going to have to change their EULA and allow that file to be installed as part of the games installation package, or they're going to have to install it onto the system during on of their Windows Updates. VB6 applications that use DirectX (and there are far, far more commercial programs doing this than some would believe) require this file. There are no if's, and's, or but's.  

    David

    Friday, February 23, 2007 10:32 PM
  • Its a violation because the EULA states that you can only redistribute the files in the form they come in the redistributable package. i.e. inside the CAB files and call dxsetup to extract them. Its reported that this isn't actually working. I'm not saying its ethically right or wrong but thats the way the EULA is worded.

    'Fully supported' is probably not a word you will actually find in a Microsoft claim. Microsoft do, IMO, a very good job of backwards compatibility for Vista with both VB6 and DirectX apps supported VERY well. But nobody will ever sign 100% in blood. For example after an escalation to the DirectX team last week we found part of DirectInput is not included in Vista for technical reasons see http://forums.microsoft.com/MSDN/showpost.aspx?postid=1198467 

    I don't doubt your claims or the significance of this - this is why I am escalating it... like I said sometimes it takes a while to get through the system. I wish there were more members of the DirectX teams who read these forums and acted on the significant issues but until that happens you are stuck with the MVPs escalating things though their channels.

    If people want to help they should call and use their free days of support for Vista and push this hard until there are multiple paths of escalation coming at the Vista and DirectX teams from all directions. It also helps if you can show a potential revenue loss.

    If people who are suffering from this issue were to post in this thread with product details (please no more opinions on the right or wrong of the situation - I think we all know the issue) then it would give Microsoft an indication of how widespread the issue is and which level of products it is affecting. Some nice big commercial products would of course help sway the case.

    Friday, February 23, 2007 11:07 PM
  • I'm sure you've probably seen this, but this is the support statement from Microsoft on VB6 and vista.

    http://msdn2.microsoft.com/en-us/vbasic/ms788708.aspx

    I can not find DX8VB.DLL on either list of supported or not supported support files. Likely because, although it's specific to VB6, it's distributed with DirectX.

    In my case, the program effected is a game called maximum-football (www.maximum-football.com). This is a commerical video game (providing both arcade play and coaching simulation).

    I simply can not upgrade that project due to;

    - Length of time to update.. it would take me months to move the code to VB.net and DirectX9

    - Cost. Microsoft isn't paying me to update, so they shouldn't be forcing me to.

    - Performance. I have a test harness that I use for testing portions of the game before they go into the central stream of code. I have upgraded one of these test harness to VB.net (although still using the DX8 COM DLL) and the performance was brutal. VB6 clearly gives better performance. (and yes, I had the .net build in release configuration). I simply can't update my code to these new technologies and then ask my customer base to go and buy brand new computers to play a game.

    - VB.Net's executables are not secure. I simply don't trust a commercial app to be left in IL. Nore do I trust the obscuficators (sp?).

    At this point, I'm telling my customer base, and potential customers to stick with WindowsXP. Those that have already migrated I tell them to download a copy of DX8VB.DLL that is available from various locations and register it with their system. At the moment, my installation package does not include that particular file, but it probably will in the next month to two months simply because it's poor customer experience to buy a game and then have to go and download system files from some 'back alley' on the Internet.

    As to your point about raising concern. I agree, everyone should. Unfortunately, my personal experience is that it goes unheard. I have even approached MSFT staff at developers conventions during break out Q&A sessions about support for VB6 and DirectX and honestly, they look at me like a deer caught in headlights. The honest feeling I get is that either they just have nobody there that understands this stuff, or nobody at Microsoft cares about the millions of visual basic developers NOT building web sites or databases. I have offered to sit down with Microsoft staff and show them the challenges (and downright impassable obstacles) they are lumping onto existing developers, but frankly they seem to just not care if you're not coding in C++/C# and using the latest, greatest (which usually it isn't) technologies.

    To give an extremely short list of the other VB6/DX8 commercial apps I'm aware of. I know of a company here in BC that builds applications that allow dentists to work with virtual models of a patents teeth prior to surgery. I know of another company that built a 3D virtual 18 wheeler driving simulator for teaching new drivers before getting on the real road. I know of another group of people building simulators in the Netherlands to simulating flooding in regions so they can properly develop dikes and other defenses.

    I also know of at least one commerical graphics engine (www.truevision3D.com) that makes use of that dll as well.   

    One other big one I forgot about. My 3D modelling program (which is what I use to create and animate my 3D models), TrueSpace 6.0 has DX8VB.DLL as a dependency. Milkshape, 3DCanvas, etc.. all have that dll as a dependency.

    So, simply put, by not properly supporting existing games & applications a lot of commercial ventures are at risk... DirectX simply isn't a C++ thing anymore...

    David

    Friday, February 23, 2007 11:34 PM
  •  DavidAWinter wrote:

    I'm sure you've probably seen this, but this is the support statement from Microsoft on VB6 and vista.

    http://msdn2.microsoft.com/en-us/vbasic/ms788708.aspx

    I can not find DX8VB.DLL on either list of supported or not supported support files. Likely because, although it's specific to VB6, it's distributed with DirectX.

    It's two issues: Other than what is explicitly listed in the link you cite above, there is no other VB6 support.  In addition, DX8 has been unsupported for quite some time.  There will not be any support for DX8VB.DLL.  It was never in the Windows Vista test matrix and never will be.

     DavidAWinter wrote:

    - Cost. Microsoft isn't paying me to update, so they shouldn't be forcing me to.

    Nor, from what I can tell, is Microsoft forcing you to adopt Windows Vista.

    The end-of-life cycle for VB6 and DirectX8 has been known for a very long time.

    Saturday, February 24, 2007 7:33 AM
  •  HighTower wrote:

    1. Is dx8vb.dll missing by design, or will it be added in later Vista DX distributions?


    As The Zman poited out, I answered this issue on this thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1223939 

    It is unsupported.  It wasn't tested for Windows Vista nor will it be.

    Saturday, February 24, 2007 7:36 AM
  • "Nor, from what I can tell, is Microsoft forcing you to adopt Windows Vista."

    That is truly bunk and you know it. New customers, buying new computers, have vista preinstalled. That means that if they want to play the game, it has to work on Vista. Which means I'm forced to migrate. So yes.. Microsoft IS forcing me to migrate code and technologies so it works on their operating system that is breaking everything. Do you honestly believe that Microsoft is not forcing new work on developers?

    By not supporting VB6/DX8 Applications, Microsoft is forcing people out of business. Or at the very least to take a serious hit in the wallet. 

    Who would not put that dll into the testing cycle of Vista? I'd like to speak to that person.

    I'm not some hobbyist. Microsoft seems to have this attitude that if you're not Electronic Arts, or UbiSoft, or Atari, you're not making real games and not worth the bother. The game sited above (which based on your lack luster post, you have not paid attention to) is how I put food on the table. It pays the bills, it puts gas in the car. No, it's not a million unit seller. It sells just enough for me to make a reasonable living. Myself, and every other independent game developer that makes their livelihood off of this sort of work is at risk because Microsoft will not properly support its products. 

    If DirectX9 properly worked with VB6 then this would be moot, but again, for reasons that have never been explained, that doesn't work either. Actually, the reasons have been explained, DX9 requires the .Net languages for managed code. What has never been explained, at least to my satisfaction, is why that decision was made. Why was there not, at the very least, a wrapper (similar to a dx8vb.dll) created to provide support for what is arguably the most common programming language in the world?

    I've offered to discuss this with Microsoft development staff for a very long time. You obviously have not read my post in full or you would have realized that and understand the extent of the situation. But all I end up with are snarky replies like yours above.

    My suggestion is that Microsoft simply change the EULA to allow for the installation of that file.

    Thank you.

    Saturday, February 24, 2007 5:24 PM
  • That's simply a mistake.
    Saturday, February 24, 2007 5:44 PM
  • Why would Microsoft want to waste time testing Vista with something that is no longer supported? VB6 and DX8 have reached end-of-life. They aren't required to test them on anything. What do you tell customers who try to run your games on Windows 3.1? You tell them they need to upgrade to a newer version of Windows. What does Microsoft tell you when you ask about using VB6 and DX8 on Vista? They tell you you need to upgrade to newer versions of VB and DX.

    The effort to migrate from VB6 to VB.NET is pretty trivial. So is the effort to migrate from DX8 to DX9. I think your time would be better spent there than trying to convince Microsoft to reverse their decision. I'm sure you know which one is likely to happen sooner.

     

    Sunday, February 25, 2007 12:54 AM
  • I have not had anyone make a request of the game to run on Win3.1 However I have had a lot of requests for it to run on Win98 and Win95.. and guess what.. it runs just fine. Neither of those OS' are supported by Microsoft.

    "The effort to migrate from VB6 to VB.NET is pretty trivial. So is the effort to migrate from DX8 to DX9."

    Perhaps in your case it is (was). But as you have never seen the code for my project, you are certainly in no position to tell me how 'trivial' it is to migrate. The fact is that it would take a considerable amount of time, and there is little benefit.. well other than it ~might~ work on vista.. but who knows.. And given that there is no performance gain (without a significant hardware update), it makes no sense.

    VB6 has not reached end of life. My goodness, there are millions of lines of VB6 code out there in the world being built and maintained every day.

     

    Sunday, February 25, 2007 1:53 AM
  •  DavidAWinter wrote:

    I have not had anyone make a request of the game to run on Win3.1 However I have had a lot of requests for it to run on Win98 and Win95.. and guess what.. it runs just fine. Neither of those OS' are supported by Microsoft.

    "Supported" and "works" are two different things. And Win98 and Win95 are as old as VB6, so I'm not surprised that it works there. However, I noticed that Microsoft is actually bending over backwards to help VB6 users leverage VB.NET and make the transition slowly over time, as evidenced at the Visual Basic 6.0 Resource Center. They even have information on how to use any .NET class from VB6. You might want to check that out if you haven't already.

    Perhaps in your case it is (was). But as you have never seen the code for my project, you are certainly in no position to tell me how 'trivial' it is to migrate.

    Point taken.

    The fact is that it would take a considerable amount of time, and there is little benefit.. well other than it ~might~ work on vista.. but who knows..And given that there is no performance gain (without a significant hardware update), it makes no sense.

    If your users are getting new computers with Vista pre-installed, then the significant hardware update probably isn't an issue. And, though you may not get a performance gain, you would certainly get access to some nifty features that aren't available in DX8.

    VB6 has not reached end of life. My goodness, there are millions of lines of VB6 code out there in the world being built and maintained every day.

     

    I won't argue with that. I wasn't speaking of practical life, but supported life. Although, based on the existance of the resource center I linked above, I would have to agree that VB6 isn't being treated as end of life. DX8, on the other hand, isn't getting squat for web space on MSDN (beyond the archived documentation), so that should be an indicator of where you stand there.

    Sunday, February 25, 2007 2:26 AM
  • In response to David Weller -MSFT answer:

    I developed my VB6 DX8.1 application in September 2002, 3 months before DX9 was released. It then entered mass retail as a CD-ROM in June 2003. Right now, my product is sitting on the retail shelves alongside Vista and for reasons already explained, it will not work.

    I am left wondering exactly what I did wrong here. Are you telling me that Microsoft consider that 4 years is an acceptable length of time to wait before breaking backward compatibility? I think most people would disagree.

    You say: "The end-of-life cycle for VB6 and DirectX8 has been known for a very long time." Well maybe. But the VB6 IDE is in extended support until April 2008 and VB6 is not compatible with DX9 only DX8. So is Microsoft supporting VB6 DX8 applications or not? It seems to me that they are and therefore the dx8vb.dll should have been included in the DX9/Vista distribution.

    Finally, you would do well to avoid comments like, "Nor, from what I can tell, is Microsoft forcing you to adopt Windows Vista." It merely shows that you are out of touch with the commercial world of software develpment. If software companies fail to support Vista then they will go bust, simple.

    Monday, February 26, 2007 3:22 PM

  • Firstly, thank you very much to the people who have posted helpful information in this thread - I've not yet had a chance to test the solution, but I hope to do so this week.

    What I don't understand, however, is why, given that it appears that the solution is simply to include two extra DLLs in a Windows Update, MS don't just go ahead and do so, thereby fixing a backwards-compatibility issue affecting the crossover of two technologies both of which they have indicated they would do their best to ensure ran on Vista.

    I could understand that they wouldn't want to put hours of coding-time into supporting outdated technologies if it was a seriously difficult task, but simply adding two pre-existing files to an installation seems so trivial as not to be worth even discussing.

    The amount of work for a large multitude of developers to competely rewrite their existing code in a new language would be massive compared to a simple fix from MS, and frankly, I can see many developers, if put in that situation, coming to the conclusion that if MS force them to put their time and effort into migrating their projects to a new platform, then perhaps it would be better to switch away from MS technologies entirely, in order to work on a platform whose designers will better support their existing customers.  Surely that can't be good business-sense, even for a company as powerful as MS?

    The idea that Microsoft isn't forcing developers to support Vista is simply laughable, as is the comparison to supporting Windows 3.1.  When software is released, it is common practice to include minimum system requirements, which often include the earliest OS version on which it will run (in my case, '95 or above).  If developers now also have to include maximum system requirements, that seems damaging for both Microsoft and the developer.  Running the latest version of Windows should ideally be beneficial in 100% of cases, rather than detrimental!

    I'm actually quite impressed with a lot of the changes made in Vista, and I would like to start recommending that people upgrade to it...  But obviously, there's no way I can honestly recommend something if it doesn't support my own software.

    Anyway, in the unlikely case that my own case adds any weight at all to Microsoft's decision to rectify this problem, I am the director of independent developer with several fairly well-known and respected freeware titles, all of which are currently coded in VB6, and we currently have two major projects in the works, also requiring VB6+DX7.

    I know I'm not alone in saying that I would be very grateful if Microsoft would put in the small effort apparently required to release a Windows Update to fix this problem.

    Anyhow, regards to all :)

    Thanks,
       Ryan J. Bury,
       RjB Software

    Monday, February 26, 2007 3:38 PM
  • The best solution here is to contact Microsoft Customer Support and open a service call. 

     

    Monday, February 26, 2007 6:40 PM
  • I've merged the 2 threads on this subject into a single one. It doesn't totally thread/read right but at least all the information is now in one place and you can reference other people to this thread. I will also change the title of the thread for better searching.

    To summarize for any future readers: (do not shoot the messenger here...)

    DX8VB.DLL and DX7VB.DLL are not included in Windows Vista by design. They were not tested, nor were they included in any beta releases of Vista. DirectX 8 and VB6 are at their end of life support.

    If you have a financial or corporate impact then the correct official path of escalation is through the normal product support services. Make sure you mention the impact on your product/company. I'm not sure if Visual Basic or Vista support is your best target.

    The only reported workaround is to include the DLLs with your installer though that is not supported nor recommended by Microsoft.

     

    Monday, February 26, 2007 7:08 PM
  • And that's going to help how exactly?

    Perhaps I misunderstand your position or purpose on these forums, but I gather from the way you present yourself that you are Microsoft Customer Support when it comes to game development on the Windows platform.

    And frankly, yet again, your response does not address the comments and concerns of developers (and I should point out, customers of Microsoft products).

    You have not addressed the technical requirement for these DLL's to be included in a Windows update.

    You have not addressed the suggestion that a change to the EULA be made to allow developers to include those DLL's in the products install package.

    You have not provided any satisfactory reason for the DLL's to be omitted in the first place. Not that any reason would really be satisfactory, they need to be there, plain and simple.

    You have not addressed the comments from developers regarding your opinion that Microsoft is not forcing developers to migrate to new technologies costing time and money the vast majority simply do not have.

     

    Monday, February 26, 2007 7:11 PM
  •  The ZMan wrote:

    I've merged the 2 threads on this subject into a single one. It doesn't totally thread/read right but at least all the information is now in one place and you can reference other people to this thread. I will also change the title of the thread for better searching.

    To summarize for any future readers: (do not shoot the messenger here...)

    DX8VB.DLL and DX7VB.DLL are not included in Windows Vista by design. They were not tested, nor were they included in any beta releases of Vista. DirectX 8 and VB6 are at their end of life support.

    If you have a financial or corporate impact then the correct official path of escalation is through the normal product support services. Make sure you mention the impact on your product/company. I'm not sure if Visual Basic or Vista support is your best target.

    The only reported workaround is to include the DLLs with your installer though that is not supported nor recommended by Microsoft.

    If possible, can you reorganize the thread by date/time of post? Posts made yesterday seem to be shown before posts made two days ago. As modified, it reads very out of order and is confusing.

    Thanks

    Monday, February 26, 2007 7:15 PM
  • No David is not customer support - he is Community Manager - which in this case means he gets to be the interface between the DirectX team and us here in the community. Right now he is just a messenger so be kind to him, he is not making these decisions. The MSDN forums are not official customer support. Depending on the product group some teams use it more that way that others but in the case of the DirectX team there is only a limited escalation channel and right now we have exhausted that channel.

    You have not addressed the technical requirement for these DLL's to be included in a Windows update.

    You have not provided any satisfactory reason for the DLL's to be omitted in the first place. Not that any reason would really be satisfactory, they need to be there, plain and simple.

    They are old and untested on Vista... you may not think it satisfactory but thats the reason they are not included and the reason they won't be in a windows update

    You have not addressed the suggestion that a change to the EULA be made to allow developers to include those DLL's in the products install package.

    If they are not supported under Vista then changing the EULA to allow you to install them on Vista would be an implied support that would be tough to handle. Also rewriting EULAs involves lawyers... you may hear back from them this time next year.

    You have not addressed the comments from developers regarding your opinion that Microsoft is not forcing developers to migrate to new technologies costing time and money the vast majority simply do not have.

    and I'm sure they won't, at least not in this forum. Microsoft employees have to be very careful what they say in public especially on contentious issues such as these. I'm sure VB6/DX8 is not the only category of app that breaks on Vista.

    Bottom line is that like DOS, Windows 3.1 and many other MS technologies over the years the DirectX team made the decision to no longer support these DLLs. They won't change that opinion based on forum posts but there is still an escalation via PSS open to you.

    I wish I could give you a more optimisitc answer, sorry.

     

    Monday, February 26, 2007 7:57 PM
  • Andy can't because the forums software is somewhat limited in that aspect.  We don't like it either :(

    Bottom line here is, as I indicated earlier: Fire off an official support request call.  These forums are for community discussions (hints, tips, best practices, etc).  Business impacts that require official Microsoft support must go through the support channels.  These forums are not monitored by the CSS team at Microsoft.

    Monday, February 26, 2007 8:04 PM
  • Business impacts that require official Microsoft support must go through the support channels.

    Then please post contact information. email addresses of real people or phone numbers preferred. Sifting through the msdn sites, and microsoft sites in general do not lead to valid contact information. You can literally spend days trying to find the correct number to call. Telling people to go through 'regular channels' and then not providing the required contact information is poor customer support.

    Comparing the lack of support of DLL's that are only 4 years old, to that of the move away from DOS or Win3.1 is not a reasonable comparison. First and foremost because the move to 32bit was a significant shift in technology of the core OS. And one that people were clamoring for. The move from XP to Vista is not a significant shift. Vista is basically a version of XP with a frustrating UAC and a fancy interface theme. It's still a 32bit OS. And one that nobody was really asking for. WindowsXP SP3 would have been sufficient. But I digress...

    David publicly claimed that Microsoft isn't forcing developers to migrate. Myself and others have pointed out that this is simply false (to put it mildly). We have provided legitimate arguments for our position. If David is going to publicly state that Microsoft isn't forcing this extra work and expense on developers, he should be backing that up.

    Bottom line is that microsoft has basically told the vast majority of developers (being those not at EA, Ubisoft, microsoft, or other major development house) to go bleep themselves.

    The only option left to commerical developers that simply do not have the resources to migrate, is to ignore the EULA.

    Monday, February 26, 2007 8:46 PM
  • Customer support is different in every country so its tough to cover everything in a forum post. However the US phone number is listed here:

    VB6

    http://support.microsoft.com/oas/default.aspx?ln=en-us&x=15&y=12&prid=24454&gprid=36680

    Vista Home Premium

    http://support.microsoft.com/oas/default.aspx?ln=en-us&x=15&y=12&c1=509&gprid=11712&

    Other products are listed here http://support.microsoft.com/select/?LN=en-us&target=assistance&x=15&y=12

    Other countries can start here and select their country

    http://support.microsoft.com/common/international.aspx?RDPATH=dm;en-us;select&target=assistance

    I'm sure you know the chances of getting a real email or phone number :-)

    Monday, February 26, 2007 8:51 PM
  • Thanks..

     I'll try those although I'm not convienced CS is the correct route to go. CS doesn't make the decisions that effect the developers.

    Monday, February 26, 2007 9:29 PM
  • PSS absolutely should escalate things into the correct product groups if its not something the immediate CS rep can handle. That is where the decisions are made. I can't say in your case it will happen but it is is the correct route. If you know any of the other people affected by this then you should encourage them to also call PSS especially if they have products and companies impacted by this decision. If you can work out a $$$ cost impact to throw into the call then I would certainly do that too.
    Monday, February 26, 2007 10:52 PM
  •  

    I guess something that wasn't mentioned so far in this thread is that going through the 'proper channels' will cost you anywhere from $100 US to $300 CAD.

    Charge: $99.00 US per request. (Some support may not be covered under this charge.) <- and this one is only applicable if you already paid for some form of special program.


    Charge: CAD295.00 per request during business hours. (Some support may not be covered under this charge.)

    So, not only has microsoft made claims that are false, but they are forcing developers to break microsoft license agreements, and also charging upwards of $300 bucks just to bring it to the next level.

    nice...

    Monday, February 26, 2007 11:51 PM
  • Sorry, been a long time since I had to call MS support and I had no idea of the prices until I looked up those links for you. I'm sure David has no clue of the current support pricing either. On the odd occasion I have had to call it was for a company who had an agreement or it was within the free period that some products have. Your Vista license should have 90 days free with it - maybe start there.

    Most companies charge for support these days. Yes its more money but if you believe you are going to lose more than $100 in revenue on your product it sounds like a reasonable return on the investment. I don't know what the policy is these days but it used to be you got a refund on the support call if the issue turned out to be an MS problem and this one sounds like it so maybe you can check that.

    Tuesday, February 27, 2007 12:05 AM
  • Thanks David W for sharing this with us, meaning me and over 5000 members in another discussion forum for game development. We are following the outcome of this issue with big curiosity.

    I wish that Microsoft was able to somehow show appreciation towards the developers that in a sense feed Microsoft by developing applications that generate more sales of the operating system, by not directing to a payphone for the masses. But naturally i do also understand that there are difficult practical issues in arranging a functional CS for such huge volumes in the first place.

    Now Microsoft must focus on finding a satisfactory solution!

    Tuesday, February 27, 2007 1:24 AM
  • As I've pointed out further up in the thread posting in here (or any other forums) isn't going to affect the outcome - Microsoft has stated . The only way that this *might* possible change is if enough people can show that supporting this DLL is impacting their business and therefor that Microsoft underestimated the impact of removing the DLL. The only way for this to happen is for those companies to call PSS with their information.

    I'm sure this does affect hobbyist developers too (I'm not sure which forum you are talking about), but I'm not sure that alone will be enough to change anything. As DavidWinter pointed out though a PSS call costs money that probably hobby developers do not have.

    If someone reading this does get traction with PSS then I'm sure the rest of us would like to hear about it.

    Tuesday, February 27, 2007 2:07 AM
  • Ok, so I recently purchased a new computer that came installed with Vista (Sony Vaio) and I'm having this same problem.

    I play alot of EA Sports NHL '07 and I use add-ons to make the game look more realistic with more realistic looking Jerseys, Ice Surfaces, etc... all of the programs that I need to install these add-ons work fine except for one called FshX. it comes up with these errors.....

    Dx8vb.dll is not installed - which I apparently fixed by downloading the the .dll. But now it says "run time error '429' Active X component cannot create object."  I know this has all pretty much been covered in this thread but I'm not too tech savvy so alot of what you guys are saying is flying over my head.

    So in basic terms is there a work around for this to get my program to work or am I just stuck?

     

    Thanks

    Tuesday, March 20, 2007 3:04 PM
  • You need to register the DLL using the command window.

    regsvr32 dx8vb.dll

    you will need to be in the directotry that you downloaded the DLL to.

    PLEASE REMEMBER that this DLL is not supported by Microsoft in Vista so downloading and using it in this way is at your own risk. You should get the author of the add-on to call Microsoft support as mentioned in this thread.

    Tuesday, March 20, 2007 4:12 PM
  •  The ZMan wrote:

    You need to register the DLL using the command window.

    regsvr32 dx8vb.dll

    you will need to be in the directotry that you downloaded the DLL to.

    PLEASE REMEMBER that this DLL is not supported by Microsoft in Vista so downloading and using it in this way is at your own risk. You should get the author of the add-on to call Microsoft support as mentioned in this thread.

     

    Ok, I tried this and came up with this

    dx8vb.dll was loaded but the call to dllregister server failed with error code 0x80070005

    I guess I'm stuck.

    Tuesday, March 20, 2007 6:21 PM
  • Hello!

     Paul Santos wrote:

    You need to register the DLL using the command window.

    regsvr32 dx8vb.dll

    you will need to be in the directotry that you downloaded the DLL to.

    PLEASE REMEMBER that this DLL is not supported by Microsoft in Vista so downloading and using it in this way is at your own risk. You should get the author of the add-on to call Microsoft support as mentioned in this thread.

     

    Ok, I tried this and came up with this

    dx8vb.dll was loaded but the call to dllregister server failed with error code 0x80070005

    I guess I'm stuck.



    To register DLLs using regsvr32 you will need administrator privileges.

    Cu, Jens
    Saturday, March 24, 2007 5:01 PM
  • Thank you Jens, but you did not state how to get the administrator privileges.  On my machine, I am listed as an administrator and every time I tried the command 'regsvr32 dx7vb.dll' it would fail with the same error code 0x80070005.

     

    After poking around the Internet with Google, I found that Vista, unlike XP, disables your administrator privileges most of the time.  In order to register the dll's successfully, start the command prompt (Start -> All Programs -> Accessories -> Command Prompt) as an administrator (right click 'Command Prompt' and choose 'Run As Administrator').

     

    Then type 'regsvr32 dx8vb.dll' at the command prompt and it should work.  You can do the same for dx7vb.dll.  Frankly, it does not make sense that MS would not include these files with Vista and yet claim to support VB6 apps for the life of Vista.  However, the writing has been on the wall for anyone coding applications in VB6 (games or otherwise) since the introduction of VB.NET (Visual Fred).  Applications written in C++ are still supported but it seems that VB developers have been shafted with the new .NET development tools and now with Windows Vista.

    Sunday, April 1, 2007 4:39 AM
  •  Gary Neal wrote:
     

    Then type 'regsvr32 dx8vb.dll' at the command prompt and it should work.  You can do the same for dx7vb.dll.  Frankly, it does not make sense that MS would not include these files with Vista and yet claim to support VB6 apps for the life of Vista. 

     

    Yes it does - these files are not, and never have been part of Visual Basic they came from the DirectX team and are part of DirectX 7 and 8 both of which are very old products. The VB team did not state they would support VB and every single COM object written to work with VB. I'm sure there are plenty of controls written to work with VB6 that no longer work in Vista.

     

    As we have repeatedly stated - if you have a commercial reason to need this support then PLEASE contact microsoft.

    Wednesday, April 4, 2007 10:39 PM
  •  

    As we have repeatedly stated - if you have a commercial reason to need this support then PLEASE contact microsoft.

     

    I believe he just did.

     

     

    Please stop telling people to spend $300 on phone calls that don't result in action. If you're to be our 'voice' to microsoft, then get microsoft to respond to the thread. And I'm not talking about David Weller that foolishly claims Microsoft isn't forcing developers to support Vista (thus forcing additional expense on them). He's already proven he's out of touch with the development community with that comment. I'm talking about the person that actually made the ridiculous decision to not include critical files. I'm, talking about the person that actually claimed these files would not be needed.

     

    People are demanding (and yes I used that word on purpose) that microsoft include these DLL's in a windows update (or service pack or whatever) so their games and other apps run. Instead of forcing people to spend even more money on phone calls, get them on this forum and provide a legitimate reason for these files to not be included. And "They were not tested" is not a legitimate reason.

     

    DirectX8 is still used by thousands of applications, games and otherwise. Heck there are Microsoft developed games that no longer work on Vista!

     

    DirectX8.1 was released November of 2001. That's a year after I purchased the computer I'm using to write this. Since that time its only upgrade was more RAM. The computer works fine. It runs WinXP just wonderfully. The DX8VB.DLL works just fine on it. That dll is only obsolete because someone uninformed claimed it was.

     

    Upgrading code and technologies should be (and up until now always has been) the decision of the developer. This decision is made based on feed back from customers, and what the developer can spend on the process. Now the decision is being arbitrarily made by Microsoft.

     

    Gary is correct. The millions of VB developers in the world have been bent over by Microsoft's move to .Net (which is not VB no matter what others claim) and now with the half hearted support of critical technologies (at least critical to VB) on vista.

     

    David

    Thursday, April 5, 2007 2:01 AM
  • We raised this issue with Microsoft through the support channels.  A formal request was made to include DX7vb.dll and DX8vb.dll on Vista (or an alternate means of providing the needed functionality) and the request was denied.  I was informed this decision is absolutely final.  During the course of this process, I was informed (off the record) that David Weller actually went to bat for the VB6 developers, but as I stated earlier, the decision to not support DirectX using VB6 on Vista is final.
    Thursday, April 5, 2007 7:48 PM
  • We raised this issue with Microsoft through the support channels.  A formal request was made to include DX7vb.dll and DX8vb.dll on Vista (or an alternate means of providing the needed functionality) and the request was denied. 

     

    I'm not sure who "we" is but...

     

    Then I want the person from microsoft that made that decision to post their rational behind it here. Publicly, in these forums. It's a very simple request that should take the person that made the decision about 10 minutes out of their busy day. Doesn't seem like a lot to ask.

     

    By making that decision microsoft has told VB6 developers that they now have no choice but to break the EULA and, as microsoft has decided to "shaft" them, (as others have put it), they have formally abandoned any chance of enforcing that EULA.

     

     

    David

     

     

    Thursday, April 5, 2007 9:09 PM
  • The "we" I refer to is me together with my employer.  The reason behind this decision, as stated to me by the support rep, had to do with with security issues and some other dependencies these dll's have that also are not being included with Vista.  The rep suggested we write a COM object in C++ to expose the DX functionality to VB6.

     

    "By making that decision microsoft has told VB6 developers that they now have no choice but to break the EULA and, as microsoft has decided to "shaft" them, (as others have put it), they have formally abandoned any chance of enforcing that EULA."

     

    No, by making that decision, Microsoft has told the developer community VB6 is deprecated and to stop using it.

     

     

    As for breaking the EULA by distributing Dx7vb.dll and Dx8vb.dll, I HIGHLY recommend against it as it would expose you to what would be the loosing end of a lawsuit.  Plus, there is no guarentee that a future patch from Microsoft would not come down that will remove these dll's from Vista because they have security issues.

     

    And one final thought, Microsoft is under NO obligation to explain to you or anyone else the reason behind their decisions to include (or not include) support for this or that functionality in new products.  If you choose to target your product for a Microsoft platform, using Microsoft development tools, it is you who must accept the risks involved when Microsoft chooses to change their platform.

    Friday, April 6, 2007 12:21 PM
  • The rep suggested we write a COM object in C++ to expose the DX functionality to VB6.

     

    Did the rep tell you who to send the bill to for the additional work microsoft has generated?

     

    No, by making that decision, Microsoft has told the developer community VB6 is deprecated and to stop using it.

     

    Not an option in a huge number of cases. VB6 is not "depreciated". It works just fine. Migrating to different programming languages that claim to be VB is not an option for many situations, including mine. I'm happy that you seem to be able to migrate to a different programming language with no wasted time or huge additional expense. That's not how it works for many people though. 

     

    And one final thought, Microsoft is under NO obligation to explain to you or anyone else the reason behind their decisions to include (or not include) support for this or that functionality in new products.
     

     

    Yes, actually, they are. Developers have PAID for Visual Studio, we've PAID for Windows, and we've PAID for various other tools and services from microsoft.

     

    So yes, they are obligated to explain the reasons behind their attempts to force developers to spend more money on forced migrations to technologies and development tools when no migration is really required.

     

     

    If you choose to target your product for a Microsoft platform, using Microsoft development tools, it is you who must accept the risks involved when Microsoft chooses to change their platform.

     

    What other platform would you suggest? For all practicle purposes, there are none.

     

     If there is a security flaw in that particular DLL, then fix it, and issue a new one. Simple.
    Saturday, April 7, 2007 12:13 AM
  •  DavidAWinter wrote:

     

    As we have repeatedly stated - if you have a commercial reason to need this support then PLEASE contact microsoft.

     

    I believe he just did.

     

    As you are WELL aware, since I've posted it in this thread already this forums is NOT a direct voice to the DirectX team. I wish it was as it would make my life simpler but its not. Sometimes you get lucky and sometimes you don't. The only formal contact to Microsoft is through the official support channels.

     

    Please stop telling people to spend $300 on phone calls that don't result in action. If you're to be our 'voice' to Microsoft, then get Microsoft to respond to the thread.

     

    Not only have I escalated this through the MVP channels, I've spent a lot of time politely answering your questions in here, I've spent time in personal emails with you and I've had several 'off the record' conversations and arguments with Microsoft people when I have had the chance to try to get you a response. And guess what - I don't get paid for this, I'm NOT a Microsoft employee so I don't get to make the decisions.

     

     And I'm not talking about David Weller that foolishly claims Microsoft isn't forcing developers to support Vista (thus forcing additional expense on them). He's already proven he's out of touch with the development community with that comment.

    Believe me, David has gone much further on this than you know.... maybe that one comment he made wasn't very smart but he is a lot more on the ball than you are giving him credit for.

     

     I'm talking about the person that actually made the ridiculous decision to not include critical files. I'm, talking about the person that actually claimed these files would not be needed.

    I feel bad for you I really do, but if you haven't worked it out - those people are not reading these forums.

     

    People are demanding (and yes I used that word on purpose) that Microsoft include these DLL's in a windows update (or service pack or whatever) so their games and other apps run. Instead of forcing people to spend even more money on phone calls, get them on this forum and provide a legitimate reason for these files to not be included. And "They were not tested" is not a legitimate reason.

    Yep I agree, it sucks. I wish they would come in here and give you what you want but given that they are very aware of this thread and they have chosen not to respond I guess you can read between the lines how important your problem is to that team. All I can suggest is that you (and the other indie developers) vote with your feet next time you choose a development platform. At least with open source you will always have the source to fall back on if it ever gets deprecated.

     

    DirectX8 is still used by thousands of applications, games and otherwise. Heck there are Microsoft developed games that no longer work on Vista!

    There are a  lot of DOS games that didn't work in Windows 95 too - on the whole games are transient programs that come and go. I fully appreciate yours is NOT but you are the exception here. Most games are released, get old and then a new game comes along. The DirectX team responds to that demand.

     

     That dll is only obsolete because someone uninformed claimed it was.

    In reality is the people who made the decision who are the informed ones. As mentioned in the other thread there are dependencies and security issues. None of us knew this until that was reported so we were uninformed. Could they fix the security issue and re release - sure given enough time and effort. Could the dependencies be made to work on Vista too - sure with enough time and effort.

     

    Upgrading code and technologies should be (and up until now always has been) the decision of the developer.

    Yes on the whole it is, but I've had many occasions when I have been forced to change tack and rewrite stuff. Every OS upgrade, not just Microsoft, has some casualties - I've lost track of the amount of hardware I have to throw out because drivers to not get upgraded to match the new OS.

     

    This decision is made based on feed back from customers, and what the developer can spend on the process. Now the decision is being arbitrarily made by Microsoft.

    Did you test your game on the Vista betas? Microsoft put those out there exactly so that people like you could test the edge cases not covered by their internal testing. Maybe Microsoft never got the beta feedback about this and therefore the fixes were low down on the priority (I don't have access to any Vista beta reporting so this is pure speculation on my part).

     

    Gary is correct. The millions of VB developers in the world have been bent over by Microsoft's move to .Net (which is not VB no matter what others claim) and now with the half hearted support of critical technologies (at least critical to VB) on vista.

    Yes the VB6 enthusiasts have made that point very clear for years now and even though there's an awful lot of them nothing as changed and VB6 is still dying right on its original schedule.

     

    As I said I REALLY wish I could fix this for you but IMO I can't see this changing, nor can I see you getting a response you are happy with. Sorry.

    Monday, April 9, 2007 6:20 AM
  •  DavidAWinter wrote:

    The rep suggested we write a COM object in C++ to expose the DX functionality to VB6.

     

    Did the rep tell you who to send the bill to for the additional work microsoft has generated?

     

    Sarcasm aside, Vista has been talked about for 2+ years, in in beta for well over 1 year before its release. Every place I have ever worked realises that operating systems can and do break applications. Its been well documented that due to driver changes there were significant changes made to DirectX itself to ensure DX9 would run on the new platform so given that your game uses DirectX I would have thought you would be testing on the new platform for a long time. Instead you report that it was your users who first informed you of the problems. Given that your userbase was inevitably going to use Vista why had you not already tested this. Now given what we know I don't know if this would have changed anything but it gets me to the point that budgeting for platform changes should be an important part of any software development project. VB6 is on its last legs - do you expect Microsoft to support it until you retire?

     

    I was a VB developer when we changed from .VBX addins to .OCX add ins - every control we used came out with a new version and every single one changed the damn API on us. Not one company offered any help. It was just the price of upgrading to the new version of VB

     

    I know as a single person company this hits you harder but its still part of doing business.

     

    No, by making that decision, Microsoft has told the developer community VB6 is deprecated and to stop using it.

     

    Not an option in a huge number of cases. VB6 is not "depreciated". It works just fine. Migrating to different programming languages that claim to be VB is not an option for many situations, including mine. I'm happy that you seem to be able to migrate to a different programming language with no wasted time or huge additional expense. That's not how it works for many people though. 

     

     

    Yes it works fine, but yes it is deprecated... at least as far as any kind of future support. Think you can get support for Delphi from Borland any more? How about Turbo Pascal? Guess what there are a handful of people out there who still use these, and still think they should be supported forever. That's just not how it works.

     

    Your points on VB.Net are valid - many others have the same opinion as you but none of those people have changed Microsoft mind. Its also not a HUGE number of cases, making those kind of claims without any figures is just as bad as Microsoft not give you reason for them dropping the DLL. You need to realize that as an VB6 developer you are perfectly within your rights to keep using it, but you are becoming a smaller and smaller group all the time.

     

    And one final thought, Microsoft is under NO obligation to explain to you or anyone else the reason behind their decisions to include (or not include) support for this or that functionality in new products.
      

     

    Yes, actually, they are. Developers have PAID for Visual Studio, we've PAID for Windows, and we've PAID for various other tools and services from microsoft.

     

     

    Nobody even outside the software industry supports everything forever. Software is particularly bad in terms of time spans but paying for something never gives an obligation to justify every decision....

     

    So yes, they are obligated to explain the reasons behind their attempts to force developers to spend more money on forced migrations to technologies and development tools when no migration is really required.

    Well I guess this is one for the lawyers...

     

    What other platform would you suggest? For all practical purposes, there are none.

    There are certainly none that would give you a hassle, free, cheap upgrade route. There are plenty of alternatives (.Net, Java, C++) - they just don't match your requirements.

     

     If there is a security flaw in that particular DLL, then fix it, and issue a new one. Simple.

    Its never just 'simple'... I'm sure the security guys at Microsoft would love for you to come and interview for a job and help them out if you think so....  it could require a breaking change to fix it (and therefore break many many other programs) the code might just be so old that its more trouble than it is worth to do it....

     

    The (unconfirmed) news of a possible security issue does seem to imply that if you break the EULA and install the DLL you may be opening yourself up for potential lawsuits from your customers even if Microsoft never came after you for breaking the EULA.

     

    As I said in the other reply, personally I feel bad for you - this is a sucky decision and I wish someone would come up with a better answer than I or anyone else is giving you but I don't think bitching is going to change anything at this point. Much as you hate to hear it - the phone call is still your recourse (assuming you have not done it) though given the other persons response I don't hold out much hope their either.

    Monday, April 9, 2007 6:58 AM
  • The reason behind this decision, as stated to me by the support rep, had to do with with security issues and some other dependencies these dll's have that also are not being included with Vista. 

     

    I don't know enough to dispute the secuity issue so that could be likley however it would seem from the forum threads here and in other places that the dependency claim isn't true since merely copying the particular file and registering it has fixed all the programs I have seen reported. The MS support staff really should not make such claims when the evidence suggests otherwise.

    Monday, April 9, 2007 7:03 AM
  • Sarcasm aside, Vista has been talked about for 2+ years, in in beta for well over 1 year before its release.

     

    Yes, beta. Meaning software that isn't finished. Testing with unfinished software from someone else is usually pointless because too many things change at the last minute.

     

    And as I mentioned to you in the past, I have brought this up to microsoft staff at developers conventions. Face to face. They were aware of the problem. They were told. Obviously they chose to ignore the warnings.

     

    Now given what we know I don't know if this would have changed anything but it gets me to the point that budgeting for platform changes should be an important part of any software development project.

     

    Under normal circumstances I would agree, however when it's a choice between spending months rewriting code and not selling a product (and not being able to pay rent or eat during that time because there's no revenue) or actually selling product that puts food on your table...hmm which am I going to chose?

     

     

    VB6 is on its last legs - do you expect Microsoft to support it until you retire?

     

    I expect them to support it until something better comes along that provides a seamless upgrade path. So far there isn't one. VB.net is not better. Certainly different, but not better. 

     

    I was a VB developer when we changed from .VBX addins to .OCX add ins - every control we used came out with a new version and every single one changed the damn API on us. Not one company offered any help. It was just the price of upgrading to the new version of VB

     

    I was as well, but if you'll remember, there were also multiple versions of VB at the time. VB4 had both 16 and 32bit versions. So developers could choose what they wanted to do and migrate as their projects allowed. My VB3 based apps still work on XP.

     

    Nobody even outside the software industry supports everything forever. Software is particularly bad in terms of time spans but paying for something never gives an obligation to justify every decision....

     

    I have to. I have no choice. I don't support my product, nobody buys it. I don't eat. It's very simple.

     

    And by the way, "outside the software industry" companies do support their products. My father can still go to Ford and get a replacement muffler for his 1986 Bronco II. Along with other parts (perhaps not from Ford in all cases, but he can get the parts). 

     

    Telecom companies still support technologies from the 1970's. And when they do 'force' their users to upgrade to new technology to make the old stuff go away, those telecom companies actually PAY the customers still using the old technology to make the move. It's cheaper for them to pay someone a couple of hundred dollars to replace their phone rather than keep the technology alive.

     

    Now I realize that a truck costing several thousands, or a telecom company with billions in hardware it's trying to upgrade, is a tad different that a software package worth a couple of thousand (which is what Visual Studio 6 cost me), but my point is that yes, many companies do support the products they sell after more than 3 years.

     

    Its never just 'simple'... I'm sure the security guys at Microsoft would love for you to come and interview for a job and help them out if you think so....  it could require a breaking change to fix it (and therefore break many many other programs) the code might just be so old that its more trouble than it is worth to do it....

     

    The (unconfirmed) news of a possible security issue does seem to imply that if you break the EULA and install the DLL you may be opening yourself up for potential lawsuits from your customers even if Microsoft never came after you for breaking the EULA.

     

    So far, any security issue is rumor and conjecture at best because as you have noted, nobody from microsoft is willing to answer questions here. My response to that statement (even if comming from a microsoft rep) is that until they can prove to me otherwise, there is no security flaw and they're using it as an excuse. Besides, according to other people from microsoft (which have posted in this thread) the DLL was never tested with vista, so how would they confirm there are security problems? 

     

    As I said in the other reply, personally I feel bad for you - this is a sucky decision and I wish someone would come up with a better answer than I or anyone else is giving you but I don't think bitching is going to change anything at this point. Much as you hate to hear it - the phone call is still your recourse (assuming you have not done it) though given the other persons response I don't hold out much hope their either.

     

    I've spend years (literally) working on this project. It was started with DX7 (because it started from the code base of an earlier title). The move to DX8 was very early in development so was not an issue. No developer, well save for those folks building Duke Nuken Forever it seems, changes graphics engines or programming languages in the middle of a project. It's just not a good idea on many levels. A project of the scope of mine would never be finished at all if I switched technology every time microsoft suggested. 

     

    And lets say I do change programming languages and switch graphics technology. Lets say someone magically appears that sponsors that. That cost is going to need to be recovered some how.. who's going to do that? I've got to go back and say.. listen customers, I know you just paid me for this but I'm going to ask for more money so you can keep playing... hmm no..

     

    Bottom line is that, and this is no exaggeration, is that this decision, which microsoft was told would cause problems, is taking food off my table. So I hope all those folks at microsoft that are sitting back enjoying their meals.

     

     

     

    Monday, April 9, 2007 5:21 PM
  • I'm acknowledging that the matter was not closed to your satisfaction, in spite of taking the path I recommended.  While I respect your frustration in this matter, this thread no longer has any technical value.  Thus, I am locking this thread.
    Tuesday, April 10, 2007 12:07 AM