View Full Version : Bugs in Trial Version 18.104.22.168
11-08-2002, 02:32 PM
I've been trying to evaluate TrueUpdate Version 22.214.171.124 trial and I'm running into some "bugs".
In the Client Configuration Utility, when building the Build Status dialog box appears. After it's finished, I have the option to Save. This options fails. It appears that your program things the file name I'm saving to, i.e., Build.txt is a directory. When running my file monitor, I get a FAILURE when ClientConfig.exe tries to open directory c:\temp\build.txt. I decided to create the Build.txt file using notepad to see what happens. Your program deletes the file.
The second bug is a bit more serious. I'm testing on my local machine using a local web server (IP: 127.0.0.1). In the client setup, I've set the Server File Location Properties: HTTP URL to: http://127.0.0.1/trueupdate/QW-TrueUpdate.uif Port: 80
When I run the Update.exe, it's trying to access IP: 126.96.36.199. NSLOOKUP sees this address as microsoft.com, which I blocked. I could only get the update to work once I unblocked that IP. Why is your software accessing microsoft's web site?
11-09-2002, 08:04 AM
It does that to make sure that you are connected to the Internet since you gave it a URL to update from. The only reliable way that we could detect an internet connection is to try to connect to some Web site on port 80. We chose Microsoft because if their Web site is down it probably means that the world has ended and there is no point in trying to update your software /ubbthreads/images/icons/smile.gif
Seriously, though, that is why we do things that way. If you give it a local path to check, it will not try to check the Internet connection at all.
As far as the save bug goes, we will look into that.
11-11-2002, 12:20 PM
That's twisted (and flawed). Why would you go to a 3rd party web site to check for the internet connection, especially Microsoft's? Are they aware that you have embedded their domain name into your distributed program and you're using their site as an "acid test"?
As a programmer your logic boggles the mind. If I gave a URL to update from, why not test for a connection to THAT URL instead? Or at the very least, if you're going to hard code, why not hard code the indigorose.com URL? Why not look for the DNS server? There's plenty of other options available and yet you took the lazy way out (which will and has caused problems).
Essentially, you've hard-coded your program to rely 100% on the hopes that Microsoft's web server is up and running. If it's not (and no the world has not come to an end...) , then it doesn't matter whether the URL I'm trying to connect to is there or not, you're program will fail the attempt. So, humor me... why is this a good method?
Anyway, I find this rather ironic. Your FAQ says you don't have any external run-time dependencies and yet, you've coded your software to be dependent on microsoft.com.
If I was in your position, I'd probably dissasemble the InternetGetConnectedState API call from wininet.dll and take the chunk of code that determines the connection state, thus removing any dependency on wininet.dll or IE4+.
11-12-2002, 04:11 AM
First of all, thanks for having a sense of humor. That's fantastic to see /ubbthreads/images/icons/smile.gif
I was looking at the source code today and we do run a quick check on microsoft.com as I mentioned before just to make sure a connection is there. I think a better idea would be to first check for a connection to the cite you are downloading from. I will make sure that gets changed for the next version.
From your message I take it that you are quite a programmer. Please do pass along any source code that you think would improve our product.
11-19-2002, 09:43 AM
You can't be a serious coder all the time... and I have comments to prove it /ubbthreads/images/icons/smile.gif
I'm glad you agree that it'd be better to check the site you're downloading from as a better method to determine your net connection. As you've could of guessed, I'm not a fan of Microsoft. It's just that my livelyhood (read: paycheck) depends on writing code that uses their OS.
I can see that the humor runs deep at your place. Do you really think I'd just "donate" my source code? Tell ya what... When I finish my own proprietary internet updating program, I'll send ya a screen-shot. /ubbthreads/images/icons/smile.gif
Seriously though, your product was almost on the mark. There were just a few things that I needed more control over that TrueUdate couldn't offer.
Powered by vBulletin™ Version 4.0.6 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.