locked
Application's issue that could become a sale for me in the near future.

    Question

  • I have an Auction Tracking/Cash Accounting Package that runs on Windows 98, ME, XP, Vista and now Windows 8.  I have also successfully ported it to Ubuntu 11.4, SCO, Haiku, Suse, and MAC OS X Lion.  I'd like to keep a customer in the Windows Camp.  The Software will not function correctly on Windows 7 it fails to write the records when compiled with Visual C/C++ Express on that platform.  It works properly with the same Visual C/C++ Express on this Copy of Windows 8 Developer Preview.  How can I satisfy this user.  I'd love to load Windows 8 Preview on his system and keep him in the Microsoft Camp.  Otherwise he wants to go to Linux.  I'd rather migrate my work back to Microsoft primarily and Linux as a last resort.  How many rules would it break to ask him to become a Microsoft partner and get the Windows 8 Developer Preview. 
    Saturday, September 24, 2011 1:38 AM

Answers

  • The problem with having your client use Windows 8 Developer Preview is that it is time-limited to less than 6 months from now (March 8th, 2012 expiration date) before it expires and won't continue to run afterward since it is a preview after all. And another thing I've yet to see anything different between Windows 8 and Windows 7 except for the additional shell add-ons when Metro UI is enabled, so I don't understand why your application doesn't work for your client on Windows 7 yet it works fine on Windows 8 developer preview on your machine. Sounds like to me your client's Windows 7 installation is either missing some required dependencies in order for your program to operate correctly or there's simply just permissions problems writing to a directory.

    Since you're the author of your own program you should be able to modify your program to log as much detailed information as possible when the error occurs about the writing of records within your program and from there should be able to debug and resolve the issue. I personally usually write my programs when in debug mode to log all API return codes and other relevant information to a log file to trace back where the error is really occurring and as to why it is occurring. Then from those details I can review the return codes and what not to come up with a solution. Reason why I am stating all of this is because it seems rather strange to me to have a client switch from an operating system that is well known to not have any serious problems to another one that is pretty much exactly what they already have to begin with. Note that I say that without any disrespect of any kind as I'm just being straight forward with you.

     

    Saturday, September 24, 2011 3:56 AM
  • I know what the problem is and there is little I can do to fix it.  The Compaq my client is using is slaved to Dual AMD 64's. The Log tells me that there is a error occuring in the pass over between processors.  HP says they have a fix but it is tied to modification of the board at an approved HP Dealer Site.  So thats where I sent him.  This one isn't Microsoft's fault.  Funny that it was the compile logs that finaly identified where the loss of data that has plagued his machine was comming from.
    :-)
    Saturday, September 24, 2011 9:26 PM

All replies

  • The problem with having your client use Windows 8 Developer Preview is that it is time-limited to less than 6 months from now (March 8th, 2012 expiration date) before it expires and won't continue to run afterward since it is a preview after all. And another thing I've yet to see anything different between Windows 8 and Windows 7 except for the additional shell add-ons when Metro UI is enabled, so I don't understand why your application doesn't work for your client on Windows 7 yet it works fine on Windows 8 developer preview on your machine. Sounds like to me your client's Windows 7 installation is either missing some required dependencies in order for your program to operate correctly or there's simply just permissions problems writing to a directory.

    Since you're the author of your own program you should be able to modify your program to log as much detailed information as possible when the error occurs about the writing of records within your program and from there should be able to debug and resolve the issue. I personally usually write my programs when in debug mode to log all API return codes and other relevant information to a log file to trace back where the error is really occurring and as to why it is occurring. Then from those details I can review the return codes and what not to come up with a solution. Reason why I am stating all of this is because it seems rather strange to me to have a client switch from an operating system that is well known to not have any serious problems to another one that is pretty much exactly what they already have to begin with. Note that I say that without any disrespect of any kind as I'm just being straight forward with you.

     

    Saturday, September 24, 2011 3:56 AM
  • I know what the problem is and there is little I can do to fix it.  The Compaq my client is using is slaved to Dual AMD 64's. The Log tells me that there is a error occuring in the pass over between processors.  HP says they have a fix but it is tied to modification of the board at an approved HP Dealer Site.  So thats where I sent him.  This one isn't Microsoft's fault.  Funny that it was the compile logs that finaly identified where the loss of data that has plagued his machine was comming from.
    :-)
    Saturday, September 24, 2011 9:26 PM