Apup Error v1.4.38 For Windows 2008 R2 64-bit

[Shyamsundarsoni]

Dear ChrisJ,

I used AutoPatcher once a week & it is completely automated task. I use apup.exe to update AutoPatcher. It can update even itself hence in the automated process, some time it was updated. Right now I have apup 1.4.38 who gives same error as AutoPatcher 6.1.8. The last that it works best when it downloads releases from autopatcher.com instead of autopatcher.net.

As you say, "the move from .com to .net should be irrelevant to your issue", which is always right but the previous version of apup wored for me on same machine, but I don't know the exact version. only I know that, it is before apup 1.4.38.

just I mention this because as ViroMan's last post "hmm... I wonder... Is the server version as anal about capitalization in folder names as linux is? If that is the case that may be why its not working. I have it looking for <windows path>/system32 Not <windows path>/System32. The other versions of windows don't care and know what I am looking for." talks about capitalization.

Windows Server 2008 Enterprise R2 never care about capitalisation of path. C:\Windows\System32 is as good as c:\winDoWS\sysTEM32 & so as to C:\WiNdOwS\sYsTeM32\. It also have SysWOW64 folder exist in Windows Folder. All this information was already provided in previous posts.

In the first post, I mentioned that the new version of apup never works with Windows Server 2008 Enterprise R2.

I also tried to execute apup.exe 1.4.38 in compatibility mode in (Windows 7, Windows Vista, Windows Server 2008 and even Windows XP SP3) with Administrator rights but it never works in compatibility mode also.

One more interesting thing abou apup 1.4.38 or AutoPatcher 6.1.8 is that, if I share AutoPatcher folder from Server & execute it on another client machine using path "\\Server\Autopatcher\apup.exe", it will use the path "\Server\AutoPatcher\" (note first \\ (double) to be converted as just single \".

Same thing also happens even if I map the share to drive letter i.e. if I map X: => \\Server\AutoPatcher & execute apup 1.4.38 from X:, it grab the path "\Server\AutoPatcher" in the log file. Due to the single \ at beginning it gives series of error & failed.

@ViroMan - can you change your code to check whether the path of executable begins with \\ & keep as it is inter of searching first : char (colon char) from executable path so that to remove previous & next characters of : from path. This update may help to use apup from client machine.

Thanking you.

[ChrisJ]

@Shyamsundarsoni

i hope you didnt think i was criticising you, i wasnt, i only thought it was relevant that a previous version had worked. i'll leave this alone

[TheAPGuy]

This is strange. The call to get system32 had not changed since before 1.4.32 even. Since you are a programmer I can reveal it to you and you can understand it.

► Show Spoiler

relevant references:
Microsoft Scripting Runtime

Code: Select all

Public Type typeFolders

    windows As Folder

    system As Folder

    system32 As Folder

    system64 As Folder

    app As Folder

    autopatcher As Folder

    temp As Folder

End Type



Public folders As typeFolders



<PrimaryInit function>

Dim FSO As New FileSystemObject

...



...

Set folders.windows = FSO.GetSpecialFolder(0)

...

Set folders.system32 = FSO.GetFolder(folders.windows & "\System32") <--- this is where you are failing.

...

Don't look at me like that, I didn't create the names of these variables... its from the older code, I just use them.

[Shyamsundarsoni]

@Shyamsundarsoni

i hope you didnt think i was criticising you, i wasnt, i only thought it was relevant that a previous version had worked. i'll leave this alone

Dear ChrisJ Sir,
I din not think & never will think that you criticising me. I just want to explain what happed in detail. If you fill some think wrong by my explanation then I am sorry

I explained in detail, may be due to the habit of teaching to my students until they understood concept clearly.

[TheAPGuy]

A teacher ehh? What do you teach?

[Shyamsundarsoni]

This is strange. The call to get system32 had not changed since before 1.4.32 even. Since you are a programmer I can reveal it to you and you can understand it.

Don't look at me like that, I didn't create the names of these variables... its from the older code, I just use them.

Dear ViroMan Sir,

I understand those names & naming conventions. The code will work fine on my laptop (win7 client) but the code for getting app and autopatcher folder may be wrong as it doen not support network drives.

I will try your code snippet directly on Windows server by tomorrow & revert you back about error.

[Shyamsundarsoni]

A teacher ehh? What do you teach?

I am a Teacher here in College to teach Graduate & Post Graduate class about various subjects like Programming Language Concept, Data Structure & Algorithms (using C / C++ / VB / Java), Language Automata, Compiler Construction, Computer Networking, Operating System Concept, System Programming & many more.

[TheAPGuy]

App is the the whole string for the current path plus application name. Autopatcher is just the path. All calls are relative to that path and a function replaces script variables with that path.
To get folders.app

Code: Select all

Set folders.app = FSO.GetFolder(app.Path)

Since app.Path is set by windows itself, I believe this "should" always return proper path even when using network paths.

A programming teacher? That's great. I really admire that kind of teacher. Been so many years since I last had a C++, data structure, and assembly class. Unfortunately this isn't C++ its crappy MS vb I did manage to convert all the code to C++ months ago (perhaps more then a year ago? That long?) however, my really old Borland 6 (ya, its dinosaur bones old) just wasn't good enough. Or rather it probably was capable, I just had gotten too damn rusty with it (I relied heavily on its proprietary functions and objects instead of C++ standard functions) and my skills. I may eventually get back into working out the kinks in the C++ code since I still believe it would be well worth it to work with that rather then be constrained by VB. There is just so much "magic" you can do with C++.

[Shyamsundarsoni]

Yes, you are right about VB, it is very simplest programming languages but C++ have very great features as VB. First it support native code compilation that always speed up program execution. If considered properly, Object Oriented Approach for problem solving is really complex, but powerful feature.

In fact Borland's Delphi is unchallenged programming language. It uses Object Pascal as its Programming Engine & provides very great & error free User Interface. it is dinosaur bone.

Ok, back to your program, I never get any error while executing your code snippet on Windows Server 2008 Enterprise R2. I attached here code & its output in immediate window

► Show Spoiler

Code: Select all

Public Type typeFolders

    windows As Folder

    system As Folder

    system32 As Folder

    system64 As Folder

    app As Folder

    autopatcher As Folder

    temp As Folder

End Type



Public folders As typeFolders



Public Sub AP_Test()

    Dim FSO As New FileSystemObject, sys As Folder

    

    Set folders.windows = FSO.GetSpecialFolder(0)

    Debug.Print "Windows folder => " & folders.windows

    

    Set folders.system32 = FSO.GetFolder(folders.windows & "\System32") '<--- this is where you are failing.

    Debug.Print "System32 (Win + Sys32) => " & folders.system32 ' <--- no, I never get error here

    

    Set sys = FSO.GetSpecialFolder(1)

    Debug.Print "Direct System folder => " & sys ' <---- no, I never get error here

End Sub

the output is as in immediate window

Code: Select all

call AP_Test



Windows folder => C:\Windows

System32 (Win + Sys32) => C:\Windows\System32 ' <---- no, I never get error here

Direct System folder => C:\Windows\System32 ' <---- no, I never get error here

[Whatacrock]

Looking at the code in the spoiler from Shyamsundarsoni -- and knowing nothing about programming but shouldn't the line "system64 as Folder" be SysWOW64 as folder ???

As I said just making an observation