AutoPatcher Forum

FYI .....

KB2481109 which applies to RDB 6.1 shows as not installed in AP even though I have KB2483614 installed which applies to RDP 7.0. KB969084 (RDP 7.0) is already part of the APUP updates in Components, so I don't think KB2481109 should be offered as an update or there needs to be a way to suppress showing that KB if RDP 7.0 is installed.
Edited by click-click, 29 March 2011 - 09:42 AM.

@click-click

This is a good post, but, we need to start asking users to abide by what has been a request on the Hotfix pages since the beginning - error reporting belongs in the release forum.

The Hotfix page was designed to be a compilation list of updates, a place to make requests - "should or can you add X update" - error reporting, failed scripts, don't belong here.

But - I like this post and would like to move #580 and #581 to a new topic regarding Remote Desktop 6 & 7 issue.

To back up, James and Cristiano had much discussion about RDC, it looks like the final decision was to support the latest version for XP - RDC7 and, KB969084 (RDP 7.0) is set to Critical=True this made it a mandatory update - makes it simple. So,

I agree, lets remove version 6 update altogether => KB2481109 - the supported version of Remote Desktop Connection for Windows XP SP3 (x86) will be 7.

Now, about detections. There are 2 versions of mstsc.exe in update KB2483614 - 6.1.7600.16722 (gdr) & 6.1.7600.20861 (qfe) - curious, which installed for you?

Can you test each of these detections separately, you don't need to install again, just remove the other detections, have only one listed, fire up AutoPatcher and see if the update gets checked again for installation, then, detected as installed. I want to know if the registry, .cat and .exe all can detect as installed.

I'm not sure I understand. The current apm for WindowsXP-KB2483614-x86-ENU.apm detects my version (6.1.7600.20861). I looked at the spoiler you supplied, but I don't understand the following change:
ComponentVersion=>6.1.7600.16385

Also, do you only want me to change
FilePath=system32:\
FileName=mstsc.exe
FileVersion=>6.1.7600.16722 to 6.1.7600.20861 and test each one?

Is there even a need to add the above entries since the current apm works fine?
Edited by click-click, 30 March 2011 - 05:48 PM.

I'll start with the 'pre' installation requirements for KB2483614

ComponentFile=system32:\mstsc.exe
ComponentVersion=>6.1.7600.16385

This is similar to OS detection, it is required by this particular update so the proper version of RDC7 is updated

- here's the code from the update.

[PreReq.RDC7.IsRightVersion]
GreatOrEqualOp = CheckFilever, System32.files, mstscax.dll , >= , 6.1.7600.16385

The only difference is I used mstsc.exe. Notice this is also the version number from the original RD7 update KB969084. With the correct OS and Component version in place, this update should get flagged for installation. That's why the other update didn't install - wrong RDC version. So the short answer is 'Yes' - for this particular update it is expecting a minimum version of RDC - 6.1.7600.16385.

How I was wanting you to confirm this was by removing all 'post' install checks from the apm file - .reg, .cat, and .exe checks. If the apm is correct this update should once again be selected for install (black) when you start AutoPatcher. I hope it is. Now, you can leave the check in place (in the apm), we know it works.

'Pre' install check example:

Now, 'post' installation checks. One at a time, and only one at a time. Confusing huh. Just like you said above, why add more, the detection already works. True, on your system, but on another system it may not be the reg entry, it may be the .cat, & .exe combo. That is why you have to test each one - one by one. Test#1 - .reg, does it work? remove. Test#2 - .cat, does it work? remove. Test#3 - .exe, does it work?

The file detections have to be a pair but I still like to test individually first.

The point is to determine if each one is enough to detect the update as installed. If your first detection (registry) works, you can put anything after it (file(s)) and the update will still be blue on the tested system. Btw, this is what Cristiano was doing for you by testing all your fixpack entries - yes it takes some time.

If I was at my machine that has my XP SP3 VM on it I would test the detections. Really, it takes maybe 5 minutes to 'cut', 'copy', 'paste' the various detections to and from the apm file, fire up AutoPatcher - test - edit apm etc. I thought you and Cristiano covered this already with the fixpack stuff?

If you can't or wont do it that's fine just let me know. It is true that either the registry or .cat detections are adequate but I simply wanted to test the .exe detection on it's own as well - just like I have it in the apm, so no, you don't need to change anything - FileVersion=>6.1.7600.16722 was what I wanted to test.

Registry test:

.Cat test:

.Exe test:

Hopefully each detection will work, each time marking the update Blue - if so... The whole Shebang:

Okay I understand now what you want.

.reg test - fix detected as installed
.cat test - crashed, but fix detected after removing "any" from = reg detection entries
.exe test - crashed, but fix detected after removing "any" from = reg detection entries
all test - fix detected as installed

So, each test detects the fix like you were hoping.


BTW, how do I reset my global upload quota? I can no longer add any screenshots.
Used 496.24K of your 500K global upload quota (Max. single file size: 3.76K)
Edited by click-click, 30 March 2011 - 10:34 PM.

Alright, thanks for your effort I edited the above Spoilers to reflect your findings with using ANY.

All the settings that work or don't work I'm not sure is by design or accident. I'm going to have to test further the idea - can the detection be removed altogether, not just remove ANY, remove...

[DetectionFile]
FilePath=
FileName=
FileVersion=

and have only the 'Registry' detection in place???

and if a file is what your testing remove...

[DetectionRegistry]
RegistryPath=
KeyName=
KeyValue=

and have only the 'File' detection in place??? We want to use both detections if possible on a finished APM to be safe - I'm referring to testing only here.

I remember when I first started helping out, not sure who mentioned it, but I was reminded to include all 3 command sections at the end of the apm file even if only one - 'Installation'- was used...

[Installation]

[Removal]

[Slipstream]

I also like to maintain a single space between them - anyway, just thinking out loud.

click-click said:

You'll need to delete existing attachments to free up space... click the drop-down next to your Username - My Settings - Manage Attachments. You should free up this space from time to time.

Remember, we have a forum issue with post image attachments - their not opening. I have spent hours looking at all the settings and I can't find the problem. I have asked Frank to take a look, he has some important stuff to deal with now so I don't know when he'll be around. For now, we all need to use a remote service. Image Shack is terrible anymore, I would avoid them. I've used KwikPiks, and imgFTW - both are easy for simple pic uploading and linking.

I'll be busy for a few days so it may not be until the weekend that I can update the XP release. I also want to shorten a few Titles and move some of the info to the Description. I admit I have issues with scroll bars. Go ahead and remove WindowsXP-KB2481109-x86-ENU.apm_files & WindowsXP-KB2481109-x86-ENU.apm - it will make the release Unofficial but it will be out of your hair for now.

gUiTaR_mIkE, on 31 March 2011 - 07:32 AM, said:

No hurry, I already had renamed the subject .apm to .ap_ to test before I reported the problem. My version is unofficial anyway because I updated the .apm for Java to detect 6u24. Current .apm for APup only detects 6u23. I posted the changes I made a while back here.

BTW, the problem with resetting the quota is that all attachments in the original posts get deleted and may cause confusion as to what the OP meant without seeing the attachment. I'll use insert image in the future.
Edited by click-click, 31 March 2011 - 08:05 AM.

click-click said:

True, but if you felt an attachment should be used indefinitely you should have used an external link. The point of the quota is to give users the ability to attach to posts to make an additional point or demonstrate something, not for AutoPatcher to be a permanent host for these attachments. How many 'failed verification' pics do we need to store. Again, at some point users should clean out the attachments and regain their upload quota, if they feel a pic is essential and needs long term storage, please use an external source like the 2 I mentioned.

If / when we do some housecleaning on the FTP they will be removed anyway.