installing to thumbdrive

[rconn]

> Could you test for the presence of a serial number on the target
> drive BEFORE getting that far?

Sure, but it's kind of like testing to see if the computer is stuffed with
guacamole before doing the registration. It's hard enough (and expensive
enough in processing time and code space) to handle the normal expected
issues; it's impossible to conceive of every way an inventive (and/or
demented) user could have bollixed up his system.

 

[Charles Dye]

And I have a "SanDisk" memory stick with no serial number. I guess I can't install there either.

Am I screwed?

Reformat the flash stick, or blow ten bucks on a new one.

 

[rconn]

> I have a WD external HD on which I can't install TCMD because Window
> does not identify it as removable.
>
> And I have a "SanDisk" memory stick with no serial number. I guess I
> can't install there either.
>
> Am I screwed?

Yup. (And so is your memory stick.) But you can probably reformat it and
magically turn it into a valid drive.

 

[rconn]

I plowed thru that and it now works. But it hosed an installation of tcmd 12.11

Take Command has encountered a problem and needs to close. Blah Blah Blah

v12 and v13 use different registry entries, and I cannot conceive of any way they could be conflicting if v12 is reading the registry. The only thing I can think of is you've got a (probably mangled) *.key file in the v12 directory, and v12 is trying to read that.

It would be useful if you replaced "Blah Blah Blah" with the actual error message.

 

[vefatica]

On Thu, 20 Oct 2011 21:46:41 -0400, rconn <> wrote:

|---Quote---
|> I have a WD external HD on which I can't install TCMD because Window
|> does not identify it as removable.
|>
|> And I have a "SanDisk" memory stick with no serial number. I guess I
|> can't install there either.
|>
|> Am I screwed?
|---End Quote---
|Yup. (And so is your memory stick.) But you can probably reformat it and
|magically turn it into a valid drive.

It works fine; always has. I'll try reformatting.

OK, now it has a serial number.

So if I uninstall from the fixed drive, delete the v13 reg key, and then install
on the stick, will it later let me also install on the fixed drive?

 

[vefatica]

On Thu, 20 Oct 2011 21:36:15 -0400, rconn <> wrote:

|---Quote---
|> Could you test for the presence of a serial number on the target
|> drive BEFORE getting that far?
|---End Quote---
|Sure, but it's kind of like testing to see if the computer is stuffed with
|guacamole before doing the registration. It's hard enough (and expensive
|enough in processing time and code space) to handle the normal expected
|issues; it's impossible to conceive of every way an inventive (and/or
|demented) user could have bollixed up his system.

I formatted that stick with XP ages ago when I bought it. It has worked well
since. I don't thing I bollixed anything; it just didn't have a serial number
when I looked with Win7.

 

[Charles Dye]

So if I uninstall from the fixed drive, delete the v13 reg key, and then install on the stick, will it later let me also install on the fixed drive?

Why would you want to uninstall? Just copy the files over. You don't even have to copy all of them; you can omit the DLLs for languages you don't use.

(Incidentally, I wanted to test the above, but didn't have a flash drive with enough free space handy; so I used a loose SDRAM card that was sitting on my desk. Worked fine.)

 

[rconn]

> So if I uninstall from the fixed drive, delete the v13 reg key, and then
> install on the stick, will it later let me also install on the fixed

drive?

As long as you don't have the thumb drive plugged in.

 

[vefatica]

> So if I uninstall from the fixed drive, delete the v13 reg key, and then
> install on the stick, will it later let me also install on the fixed drive?

drive?

As long as you don't have the thumb drive plugged in.

Apparently not so! My stick-install was apparently successful ... got a key file.

After ejecting the stick and trying to re-install on the hard drive, all I get is "add/remove features", "repair", and "remove".

What do I do now?

 

[rconn]

> After ejecting the stick and trying to re-install on the hard drive, all I

get

> is "add/remove features", "repair", and "remove".

Do an uninstall and then an install.

This is a Windows Installer issue -- it knows you installed on another
drive, and now it can't find that drive so it offers to repair the
installation.

We don't support installing both to the registry and to a USB drive on the
same machine. Pick one or the other.

 

[vefatica]

On Thu, 20 Oct 2011 23:11:16 -0400, rconn <> wrote:

|Do an uninstall and then an install.
|
|This is a Windows Installer issue -- it knows you installed on another
|drive, and now it can't find that drive so it offers to repair the
|installation.
|
|We don't support installing both to the registry and to a USB drive on the
|same machine. Pick one or the other.

Are there any more surprises in store for us?

 

[rconn]

> Are there any more surprises in store for us?

Yes -- I'm removing the USB registration in the next build.

It was intended for corporate tech support users, but instead it's
generating an enormous amount of support issues from a tiny minority of
users who apparently don't even have a real need for it. It will simplify
everybody's lives if it disappears.

 

[Kachupp]

: ---Quote---
: > Are there any more surprises in store for us?
: ---End Quote---
: Yes -- I'm removing the USB registration in the next build.
:
: It was intended for corporate tech support users, but instead it's
: generating an enormous amount of support issues from a tiny minority of
: users who apparently don't even have a real need for it. It will simplify
: everybody's lives if it disappears.

This is what happens when you anger the son of god people you are lucky enough to have
such a pleasing one at that.

Could you possibly bring back the runtime library for those corporate types that could
find such a purpose extremely useful?

 

[David Marcus]

It will simplify everybody's lives if it disappears.

And, reduce the number of posts to read in the forum.

 

[Steve Fabian]

From: rconn
| Quote:
|| Could you test for the presence of a serial number on the target
|| drive BEFORE getting that far?
|
| Sure, but it's kind of like testing to see if the computer is stuffed with
| guacamole before doing the registration. It's hard enough (and expensive
| enough in processing time and code space) to handle the normal expected
| issues; it's impossible to conceive of every way an inventive (and/or
| demented) user could have bollixed up his system.

I would look at it as part of checking that the target has all the features (e.g., sufficient diskspace) required to support installation. I am sure the list is relatively short.

In re terminating portable installation support: undoubtedly you have many of us non-corporate customers who act as system repairers, often in a volunteer capacity, who whould never attempt doing it without their portable TCMD. So I, too, would humbly request continuing it in future versions...
--
Steve

 

[drrob1]

THAT needs to be very clear!

I've said this before. The process of installing to a thumbdrive is
very pooryly documented. There are problems w/ it.



On 10/20/2011 11:11 PM, rconn wrote:

> We don't support installing both to the registry and to a USB drive on the
> same machine. Pick one or the other.
>

 

[drrob1]

It's a standard Windows generic error box with no information.
But when I clicked somewhere where it said more information, it said this:

AppName: tcmd.exe
AppVersion: 12.1.1.76
ModName: kernel32.dll
ModVersion: 5.1.2600.5781
offset: 00012afb


There is a takecommand.12.10.key file in that directory. Does it belong
there? Its timestamp is back in Mar 11.

AFAIK, I'm not the only one that has reported this behavior. You did
not take it very seriously in those other reports either.

Isn't it possible that this registration scheme is having unintended
consequences. IE, bugs?


I also have tcmd 11 on that computer. That works but gives errors about
its startup file. I have to plow thru 2 or 3 errors before it starts.


On 10/20/2011 10:10 PM, rconn wrote:

> ---Quote (Originally by drrob1)---
> I plowed thru that and it now works. But it hosed an installation of tcmd 12.11
>
> Take Command has encountered a problem and needs to close. Blah Blah Blah
> ---End Quote---
>
> v12 and v13 use different registry entries, and I cannot conceive of any way they could be conflicting if v12 is reading the registry. The only thing I can think of is you've got a (probably mangled) *.key file in the v12 directory, and v12 is trying to read that.
>
> It would be useful if you replaced "Blah Blah Blah" with the actual error message.
>
>
>
>
>

 

[drrob1]

Really. That's the main reason I decided to get v 13.

Pity.




On 10/20/2011 11:58 PM, rconn wrote:

> ---Quote---
>> Are there any more surprises in store for us?
> ---End Quote---
> Yes -- I'm removing the USB registration in the next build.
>
> It was intended for corporate tech support users, but instead it's
> generating an enormous amount of support issues from a tiny minority of
> users who apparently don't even have a real need for it. It will simplify
> everybody's lives if it disappears.
>
>
>
>
>

 

[rconn]

> I've said this before. The process of installing to a thumbdrive
> is very pooryly documented. There are problems w/ it.

The problem is not with Take Command, it's with Windows and the Windows
Installer, which do not support installing multiple instances of the same
application version. Lacking the source code for either Windows or the
Installer, there's not much I can do about that.

But since the USB drive registration will be removed in build 28, it will no
longer be an issue.

 

[rconn]

> Really. That's the main reason I decided to get v 13.
>
> Pity.

I'll be happy to refund your upgrade cost if you want to revert to v12.

At some point in the next few weeks, I will offer users an optional addon
thumbdrive with Take Command preinstalled (for a nominal additional cost)
with their v13 orders. That will (1) avoid the problems with Windows
Installer refusing to install twice on the same machine; (2) satisfy the
corporate users; and (3) eliminate the barrage of bug reports and complaints
from the end users who don't actually have any use for this.

 

[rconn]

> It's a standard Windows generic error box with no information.
> But when I clicked somewhere where it said more information, it
> said this:
>
> AppName: tcmd.exe
> AppVersion: 12.1.1.76
> ModName: kernel32.dll
> ModVersion: 5.1.2600.5781
> offset: 00012afb

The crash is in Windows, not in Take Command. I will need the TCMD.GPF file
to have any clue where TCMD.EXE is in the startup process when it calls the
afflicted Windows API.

But I doubt it's related to the registration process, as none of that code
is calling anything in kernel32.dll. More likely something has gotten
munged in your v12 startup configuration. You can reset that back to the
defaults by starting REGEDIT and going to "HKEY_CURRENT_USER\Software\JP
Software\Take Command 13.0", and deleting the "Settings" key.

> There is a takecommand.12.10.key file in that directory. Does it
> belong there? Its timestamp is back in Mar 11.

It doesn't matter; it isn't used. You can remove it without affecting
anything.

> AFAIK, I'm not the only one that has reported this behavior. You
> did not take it very seriously in those other reports either.

AFAIK, you *are* the only one that has reported this behavior.

Anybody else seeing this?

> Isn't it possible that this registration scheme is having unintended
> consequences. IE, bugs?

That seems improbable, given that there is no congruence between the v12 and
v13 registry keys.

> I also have tcmd 11 on that computer. That works but gives errors about
> its startup file. I have to plow thru 2 or 3 errors before it starts.

That's to be expected, given the new directives since v11.

 

[rconn]

> Could you possibly bring back the runtime library for those corporate
> types that could find such a purpose extremely useful?

I would, if anybody would actually buy it.

We had a lot of requests for it in the past, but when we actually created it
nobody (well, maybe a half-dozen users) actually bought it. I wouldn't
recreate it at this point without some significant pre-orders.

 

[Charles Dye]

But since the USB drive registration will be removed in build 28, it will no longer be an issue.

That's a shame. Not a crying shame, because TCC/LE (also) works fine from a removable drive. But a shame nonetheless -- you did advertise the feature, and put in the effort to make it work.

May I make a suggestion? Keep the code as is; de-document the feature.

 

[Charles Dye]

If that's a "Y" = "why", then formatting will probably put a serial number on the USB stick.

Well, yes; but that's secondary. If a disk doesn't have a volume serial number, then it doesn't have an extended BPB; and if the formatter doesn't create extended BPBs, then it may have other, even worse issues. Issues which could conceivably lead to scrambled data in rare-but-demonstrable situations. The programmer might be doing things like putting his company's name -- or his cat's name -- in the OEM name field.

You really want to reformat any disk that doesn't have a volume serial number. In fact, I'd recommend reformatting every new disk -- but the absence of a serial number is a red warning flag.

 

[vefatica]

On Fri, 21 Oct 2011 08:59:47 -0400, rconn <> wrote:

|---Quote---
|> Really. That's the main reason I decided to get v 13.
|>
|> Pity.
|---End Quote---
|I'll be happy to refund your upgrade cost if you want to revert to v12.

It was #2 on v13's "What's new" feature list. This will be the most significant
in-version change I can recall.

I'm curious ... were you not getting the same complaints from those corporate
tech who do have a use for the feature; how were they managing to use it without
the same difficulties reported here? That is, how was it intended to be used?

|At some point in the next few weeks, I will offer users an optional addon
|thumbdrive with Take Command preinstalled (for a nominal additional cost)
|with their v13 orders. That will (1) avoid the problems with Windows
|Installer refusing to install twice on the same machine; (2) satisfy the
|corporate users; and (3) eliminate the barrage of bug reports and complaints
|from the end users who don't actually have any use for this.

Reasonable, but won't that be a hassle for you?

Is there more than the drive's serial number involved? Couldn't you email a
key-file to those qualified users who provide a USB-device serial number and
whatever other info might be needed.

Under any scenario, how would "OPTION /U" work with TCMD on a thumb drive. It
would seem now that it would mess up a permanent installation on the current
machine.

 

[rconn]

> It was #2 on v13's "What's new" feature list. This will be the most
> significant in-version change I can recall.

The "What's New" list has never been in any order of significance. I would
classify USB registration as rather less than 1/10000 as significant as VIEW
or command dialogs.

Since you already said you had no use for this feature (like 99.9% of the
rest of the user base), I don't see it as a noticeable issue.

> I'm curious ... were you not getting the same complaints from those
> those corporate tech who do have a use for the feature;

Nope. Zero. None.

> how were they managing to use it without the same difficulties
> reported here?

They weren't attempting the (impossible in Windows) multiple installations
of the same version on the same machine.

> Reasonable, but won't that be a hassle for you?

I don't expect to get many orders.

> Is there more than the drive's serial number involved? Couldn't you email

a

> key-file to those qualified users who provide a USB-device serial number

and

> whatever other info might be needed.

Not without throwing out the entire registration system. The registration
server has to be called with the activation key from the machine where the
permanent key will be installed.

> Under any scenario, how would "OPTION /U" work with TCMD on a
> thumb drive. It would seem now that it would mess up a permanent
> installation on the current machine.

And that's why I said not to install the same version repeatedly on the same
machine ...

 

[Charles Dye]

In fact, I'll make you an offer. If you choose to retain the ability to register from removable drives, then I'll write the how-to for you. A step-by-step guide ought to calm the waters.

(Yes, I'm aware that this feature is for a vanishingly tiny percentage of your user base....)

 

[drrob106]

As the tech savy guy in a small dept I am asked to help with computer problems. This portability is useful. Why does Rex say who needs portability and who doesn't. This is a tech oriented product.

Sent from my Verizon Wireless 4GLTE smartphone

----- Reply message -----
From: "Charles Dye" <>
To: <[email protected]>
Subject: [Support-t-3295] Re: installing to thumbdrive
Date: Fri, Oct 21, 2011 11:25 am


In fact, I'll make you an offer. If you choose to retain the ability to register from removable drives, then I'll write the how-to for you. A step-by-step guide ought to calm the waters.

(Yes, I'm aware that this feature is for a vanishingly tiny percentage of your user base....)

 

[vefatica]

On Fri, 21 Oct 2011 11:17:52 -0400, rconn <> wrote:

|---Quote---
|> Under any scenario, how would "OPTION /U" work with TCMD on a
|> thumb drive. It would seem now that it would mess up a permanent
|> installation on the current machine.
|---End Quote---
|And that's why I said not to install the same version repeatedly on the same
|machine ...

So each person wanting to use a mobile TCMD is expected to have a dedicated
machine (without a permanent TCMD) where the install and upgrades take place.
And he/she has to take care to ensure that with every upgrade the removable
device has been mounted with the same drive letter. That seems very awkward.

 

[Steve Fabian]

From: rconn
| Quote:
|| I also have tcmd 11 on that computer. That works but gives errors
|| about its startup file. I have to plow thru 2 or 3 errors before it
|| starts.
|
| That's to be expected, given the new directives since v11.

Not if separate .INI files are used, which would be guaranteed if they are in the default locations (same directory as TCMD). I have all version since 5 on my system, each in a separate subdirectory of F:\JPSOFT\, and a unique command line, specifying the version-appropriate .INI file. No problems! The directives which are unchanged are in a .INI file which is invoked using the INCLUDE directive. A shared 4START.BTM/TCSTART.BTM has version-dependent parts.
--
Steve