Hi, Igor
![Smile :-)](./images/smilies/icon_smile.gif)
Thanks for your reply. My post is delayed, sorry, but I write this reply second time - first has been eaten by my browser and your server
![Smile :-)](./images/smilies/icon_smile.gif)
))
Igor wrote:Hi Witrak(),
Thanks for the feedback and find my replies below.
witrak() wrote:
I come back to the problem. As you wrote some months' ago in reply to neo314 post, the reason for the error is DEP. I have had DEP set on for all programs. Now I have changed DEP setting for USBSafelyRemove and it starts from unprivileged account too.
However I'm afraid it isn't good solution:
1) If it from the beginning have worked from admin account and DEP=on wasn't any problem, why for unprivileged account it is a problem?
I actually does not understand fully your current conditions (and the problem as well). What settings for what accounts do you have? Do you run the program from non-administrative account and it crashes, while it works flawlessly under an administrative account?
Now everything is OK: I have changed DEP to off (selectively, only for USBSR) and program starts as it should (during Windows boot) and works according to the description: is available from all accounts, privileged and unprivileged.
Igor wrote:
2) If you knew about the problem, why you did not explain it in the installation docs?
I believe 99.9% of users do not know what's DEP. Also the problem might happen if DEP is enabled but non always, I'd say very rare. This problem is more about incompatibility of the program with the specified hardware. E.g. on my own computers I have DEP enabled and the program works flawlessly for administrative and restricted accounts.
...
Igor wrote:
4) Assuming the situation is only some effect of programming style
and USBSafelyRemove really does only what it should do, what about other potential problems you do not mention in documentation?
Actually the program in this case just doesn't work on a specified configuration. It doesn't cause problems isn't it? In this case we can only mention that "on some rare configurations with DEP enabled the program might not work". But I'm not sure that this information helps.
For example, what about potential conflict between two (or more) instances, started from different accounts (eg. normal and elevated privileges account)?
We are trying to spend our time on fixing the problems as soon as users encounter them and report us rather than on writing this problems to documentation. I think it's better for product.
Well, typical programs work correctly always or never. Thus it is unreasonable to put effort into creating description of their anomalous behavior, because if such program doesn't work for a user because of some rare incompatibility then there is high probability it will never work for the user (and if this user have paid for it then s/he will contact support).
Obviously USBSR is NOT typical program. It has to be complicated, as it must cope with different hardware, unspecified interface [Windows
![Sad :-(](./images/smilies/icon_sad.gif)
] etc. Thus it is a chance that it may not work properly in much higher number of cases. Some of them are unavoidable (incompatibility cases...) but some have to be related to programers' work - not even errors, but results of long evolution of program code during development of the product.
For sure a *clean* program written *from the beginning with limitations of DEP in mind* will work with DEP set to ON disregarding any other (technical) code dependencies.
I expect the producer (you...) should do *anything* to make my (the potential buyer's...) problems as rare as possible.
It means: if there is possible that explanation of rare case when program may not work may help the user to overcome problem or at least to improve situation, the explanation should be prepared and put in some easy to find place.
If you don't care because such situation concerns a small percentage of people supporting your business then you *send clear signal* to these people: "I don't care"
So I don't agree with you in all points above.
Igor wrote: 5) Taking into account everything, don't you think your price list is rather appropriate for more mature product?
I believe our product is enough mature comparing to other products, since there are no programs on the Earth that works on absolutely all hardware configurations and doesn't have bugs at all. Anyway I'd be happy if you share here your thoughts about how much the program should cost.
That's your opinion (about programs) and probably also opinion of part of users. However I would argue...
As for prices there is my opinion (I only think about prices for regular users, not business users.)
1) The basic price ($20) is acceptable, but as for a utility program it is high even if it covers 1 yr upgrade subscription, because final release still has important faults.
2) Upgrade subscription price ($10/yr) is too high: taking into account USBSR reached its final form and future upgrades will only repair errors and expand compatibility to new devices "upgrade" means really "support". And 50% of license price is too much. I would propose change of upgrade subscription period to 2 years and price of it to $14 - $15. You cash in advance what means your real gain is even higher.
3) Unlimited upgrade subscription price is absolutely too high. "Unlimited" means in reality "until producer cease to exist or program is discontinued, whatever happens first". In practice utility programs life time is comparable to OS version life time. After that a new version of utility is released (with new price tag of course
![Smile :-)](./images/smilies/icon_smile.gif)
) or totally new product is entered into market (what in fact have taken place
![Wink ;-)](./images/smilies/icon_wink.gif)
).
Thus you should calculate program with unlimited upgrade subscription price as:
license price ($20) + 2*[2yr upgrade subscription price (2*$14) - discount] = $20 + ($28 - discount),
and for 4yrs period discount should be about 50%, what means roughly $35 in total.
Another thing is your taxing schema. I don't understand why you present prices without *any mention* it doesn't include VAT ? This is against common practices and a little (?) unfair.
Second, why your business partner - who you declare do for you only payment technical operations - adds VAT according to EC regulations ? Your firm is not registered in EC so you should sell at prices including Russia VAT, shouldn't you ?
Regards,
witrak()
PS. My nick is witrak() - with parentheses but without capitalizing "w"
![Wink ;-)](./images/smilies/icon_wink.gif)