One for AlecStaar regarding APKRamCharge.exe
Just downloaded AlecStaar's lastest tool pack for Windows XP. I'm having problems with the ramcharge program though (and since I deleted the old archive I can't restore the version from the previous release).
Just downloaded AlecStaar's lastest tool pack for Windows XP. I'm having problems with the ramcharge program though (and since I deleted the old archive I can't restore the version from the previous release).
Anyhow whenever I run the program I get '14/6/2004 is not a valid date' over and over until I kill the process through taskman. How to I get rid of this and what is causing it? I've checked the registry and the .ini files in the APK folder but nothing obvious springs to mind.
Anyhow whenever I run the program I get '14/6/2004 is not a valid date' over and over until I kill the process through taskman. How to I get rid of this and what is causing it? I've checked the registry and the .ini files in the APK folder but nothing obvious springs to mind.
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
So basically what you are trying to say summed up in a neat sentence is that the application won't work on my PC because it's not set to a US time zone?!
**sigh**
I can understand why as a developer you would want to ensure that those who use your programs pay for them. But you are losing money and potencial users by restricting your software in this way. There are I'm sure plenty of users (living outside the USA) who would pay for the software (provided it was a resonable price).
One final point I think it is only fair (if you haven't done so already) that you state that the product won't work outside of the US on the downloads webpage (granted I got mine from a mirror site, but it was one of your links). As there are likely to be alot of people, me included, that are more than a bit miffed at wasted download (and troubleshooting) time. 17mb may not seem alot but I am on a very slow unreliable dial-up! ;(
**sigh**
I can understand why as a developer you would want to ensure that those who use your programs pay for them. But you are losing money and potencial users by restricting your software in this way. There are I'm sure plenty of users (living outside the USA) who would pay for the software (provided it was a resonable price).
One final point I think it is only fair (if you haven't done so already) that you state that the product won't work outside of the US on the downloads webpage (granted I got mine from a mirror site, but it was one of your links). As there are likely to be alot of people, me included, that are more than a bit miffed at wasted download (and troubleshooting) time. 17mb may not seem alot but I am on a very slow unreliable dial-up! ;(
Quote:* You see, statistically 90% or better of my buyers have been U.S. customers so I cater to them exclusively since I have been tracking paying geographic area purchasers over time since 1997... & they represent the bulk of my 'buying public' over time.
You see, now that's exactly the kind of attitude that gives us American's a bad rap... Although, how can you expect your international sales to develop when you refuse to support them?
But seriously, I don't understand why you don't put just a little extra coding effort into it to make it independent of the date format. A little quick research and I came up with something that should work. Just change your code that is currently "If Date > StrToDate(Trim('6/14/2004')) then ..." to "If Date > EncodeDate(2004, 6, 14) then ..." -- not that much more work, probably less even from the processor side (fewer function calls, no string processing), and you've got better international support!
Of course it is your program, so do what you like...
Quote:It also looks for many disassemblers in RAM as well & will shutdown upon detecting them & reboot the system.
(AND, That's me being nice too, because I figure most folks would blow or corrupt critical system files if someone tried to hack their work I would guess... I could, but don't!)
[rant]By the way, I would be fucking pissed if you did this to me (hack my system) - enough so that I would NEVER use your products. Plus I would tell everyone I know to never use your products, and I would tell all the providers that host your files that you hacked my system with the program. And I would shun you on this forum. There are legitimate reasons for running debuggers / disassemblers, and immediately assuming that any such program is being used to hack your program is a great way to alienate users. I know you are just protecting yourself, but I think any scheme that has a negative impact on legitimate users is never worth it. Whatever happened to "the customer is always right"?[/rant] So I guess it's good that you're nice...
You see, now that's exactly the kind of attitude that gives us American's a bad rap... Although, how can you expect your international sales to develop when you refuse to support them?
But seriously, I don't understand why you don't put just a little extra coding effort into it to make it independent of the date format. A little quick research and I came up with something that should work. Just change your code that is currently "If Date > StrToDate(Trim('6/14/2004')) then ..." to "If Date > EncodeDate(2004, 6, 14) then ..." -- not that much more work, probably less even from the processor side (fewer function calls, no string processing), and you've got better international support!
Of course it is your program, so do what you like...
Quote:It also looks for many disassemblers in RAM as well & will shutdown upon detecting them & reboot the system.
(AND, That's me being nice too, because I figure most folks would blow or corrupt critical system files if someone tried to hack their work I would guess... I could, but don't!)
[rant]By the way, I would be fucking pissed if you did this to me (hack my system) - enough so that I would NEVER use your products. Plus I would tell everyone I know to never use your products, and I would tell all the providers that host your files that you hacked my system with the program. And I would shun you on this forum. There are legitimate reasons for running debuggers / disassemblers, and immediately assuming that any such program is being used to hack your program is a great way to alienate users. I know you are just protecting yourself, but I think any scheme that has a negative impact on legitimate users is never worth it. Whatever happened to "the customer is always right"?[/rant] So I guess it's good that you're nice...
Quote:I have never seen this "EncodeDate" function call, I may look into it when I find the time for it, provided Delphi has such a function... if not, I can find its analog in VB or C & port it.
Just looked it up, I can use it... does not look too bad, but it will have to wait until next June rebuild release (I already have 8 things I have to add or improve already).
Thanks for the tip!
No problem!
Quote:Quote:There are legitimate reasons for running debuggers / disassemblers, and immediately assuming that any such program is being used to hack your program is a great way to alienate users.
Really? What reasons are those IF YOU HAVE YOUR OWN SOURCECODE??
Anti-virus programmers wouldn't be able to do anything without disassemblers. Or how about consultants working on old binaries, perhaps to convert it to a new machine (requires an ASM translation). Or, a moot reason now, but people trying to locate y2k bugs in programs whose source code is long gone.
I know that these occasions are few and far between, but I am debating this from a philisophical side more than any. A disassembler itself is a legitimate tool. Just as a knife is used to cut things - but what the user chooses to cut is what classifies the tool. But as you say, the only time you would use a disassembler is when the source code is not available. And I would agree, this is most often (but not always) the case when you are trying to reverse engineer or hack someone else's work.
One thing I just thought of, is that Visual Studio's debugger will disassemble a program if the source code is not available. Which means that it obviously has a disassembler... Would your program complain about having VS open? In fact, I think most debuggers can disassemble a running process. So this is in fact a quite legitimate use that you may conflict with.
Quote:All the memory freeing programs out there? Just copies of MY work, it was the first of them all in RamCharge & used to make me ALOT OF MONEY...
My commercial product market was killed by the copies.
It's all about innovation man... when your product was first out there, it did well because you were the only one doing it, and it was a cool idea. But if other companies see that idea and think they can do it better/cheaper/whatever, then I say more power to them. And I seriously doubt that ANY of the RAM-freeing programs out there are a result of disassembling your program.
Quote:A canard, a prevarication... b.s. used to placate the person being ripped off is what that is if you ask me a good 50% of the time is what.
Let me make that IMCOMPLETE SAYING, complete (at least in my book):
"The PAYING customer is always right!"
Ah, but that BS is what makes happy customers => repeat customers, and word-of-mouth from happy customers is IMHO the best form of publicity. And of course the "paying" part is implicit, but there is a chance that one of your payed customers would need to use a disassembler, or an even better chance that one of your customers would be developing/debugging their own programs.
Now, let me repeat, I am arguing this mostly from a philisophical point of view. (plus it's fun to be devil's advocate ) From an objective point of view - I think that even your "reboot the system" tactic is a bit much. That is intruding on areas of my computer that I didn't give permission for. And as I gave you a perfectly good reason why I might have a disassembler open (ie running a debugger), your action is unwarranted. If you still don't want to let people run your software in that scenario, fine, but just quit the program. When you start doing things without asking me, that is unethical behavior, and I am more likely to get annoyed and just find some other toolset.
Whew.
I can forsee this conversation getting way out of hand, but I guess we'll see what happens...
ps - from my perspective this is all hypothetical anyway, as I have never used your tools, nor any tools like it. I am just imagining myself in situations where your choices might adversely affect my decision to buy your software...
Just looked it up, I can use it... does not look too bad, but it will have to wait until next June rebuild release (I already have 8 things I have to add or improve already).
Thanks for the tip!
No problem!
Quote:Quote:There are legitimate reasons for running debuggers / disassemblers, and immediately assuming that any such program is being used to hack your program is a great way to alienate users.
Really? What reasons are those IF YOU HAVE YOUR OWN SOURCECODE??
Anti-virus programmers wouldn't be able to do anything without disassemblers. Or how about consultants working on old binaries, perhaps to convert it to a new machine (requires an ASM translation). Or, a moot reason now, but people trying to locate y2k bugs in programs whose source code is long gone.
I know that these occasions are few and far between, but I am debating this from a philisophical side more than any. A disassembler itself is a legitimate tool. Just as a knife is used to cut things - but what the user chooses to cut is what classifies the tool. But as you say, the only time you would use a disassembler is when the source code is not available. And I would agree, this is most often (but not always) the case when you are trying to reverse engineer or hack someone else's work.
One thing I just thought of, is that Visual Studio's debugger will disassemble a program if the source code is not available. Which means that it obviously has a disassembler... Would your program complain about having VS open? In fact, I think most debuggers can disassemble a running process. So this is in fact a quite legitimate use that you may conflict with.
Quote:All the memory freeing programs out there? Just copies of MY work, it was the first of them all in RamCharge & used to make me ALOT OF MONEY...
My commercial product market was killed by the copies.
It's all about innovation man... when your product was first out there, it did well because you were the only one doing it, and it was a cool idea. But if other companies see that idea and think they can do it better/cheaper/whatever, then I say more power to them. And I seriously doubt that ANY of the RAM-freeing programs out there are a result of disassembling your program.
Quote:A canard, a prevarication... b.s. used to placate the person being ripped off is what that is if you ask me a good 50% of the time is what.
Let me make that IMCOMPLETE SAYING, complete (at least in my book):
"The PAYING customer is always right!"
Ah, but that BS is what makes happy customers => repeat customers, and word-of-mouth from happy customers is IMHO the best form of publicity. And of course the "paying" part is implicit, but there is a chance that one of your payed customers would need to use a disassembler, or an even better chance that one of your customers would be developing/debugging their own programs.
Now, let me repeat, I am arguing this mostly from a philisophical point of view. (plus it's fun to be devil's advocate ) From an objective point of view - I think that even your "reboot the system" tactic is a bit much. That is intruding on areas of my computer that I didn't give permission for. And as I gave you a perfectly good reason why I might have a disassembler open (ie running a debugger), your action is unwarranted. If you still don't want to let people run your software in that scenario, fine, but just quit the program. When you start doing things without asking me, that is unethical behavior, and I am more likely to get annoyed and just find some other toolset.
Whew.
I can forsee this conversation getting way out of hand, but I guess we'll see what happens...
ps - from my perspective this is all hypothetical anyway, as I have never used your tools, nor any tools like it. I am just imagining myself in situations where your choices might adversely affect my decision to buy your software...
Quote:Possibly, but a hex editor would be able to ID the same area in a program near its ending by knowing the look of instructions for the jump table many executeable type virus use, & then alter that, OR go to the end of the program where the virus attaches itself & search for its unique string there (this IS its mugshot, that unique codestring used to ID it but looking at it in its binary form instead of Assembly instructions instead in a debugger).
A hex editor is not all that different from a disassembler. If I wanted to, I could take a hex editor and translate each byte into the corresponding op-codes. This is all that a disassembler is doing; it just automates the process...
Quote:Quote:One thing I just thought of, is that Visual Studio's debugger will disassemble a program if the source code is not available. Which means that it obviously has a disassembler... Would your program complain about having VS open?
Nope, I don't watch for that. It is a legit tool as far as I am concerned, but its debugger only activates iirc, if a program crashes & you replaced DrWatson with it.
Not true... I can open up ANY running process simply by going to Tools -> Debug Processes. It will attach to the process, and then I can pause it, browse through the code, and do all the standard debugging stuff. If you have the source code and it was compiled with debugging symbols, then it will show your position in the original source. But even if you don't have the source code and there are no debugging symbols, it will still show you the disassembled code. To test this, I just attached to iexplore.exe and started stepping through the code - not a problem! Of course I have no reason to go wading around through x86 assembly. Ugh! If you've ever developed assembly for any other processor, you'll know how horrid x86 assembly is.
Quote:The main point is, having a debugger around is one thing, knowing how to use it is another... additionally, even if you do, it's NOT all that easy to use to disassemble for a particular branch of code anyhow. With today's code using runtimes &/or .VCL or .OCX & .DLL calls, that code often branches to prebuilt code from the OEM for those things, not code that is unique & written by the developer that is the prize sought by the hacker.
Well hell, if you can't figure out how to use a debugger effectively, then you're not going to get anywhere digging through assembly...
Quote:Still, guys are out there that know how it's done, & have the patience for it. I have had it done is why I protected against it, & saw my work on Wahh-rezz sites in the past enough to know its done... I was using canned shareware protectants back then. They failed me.
My guess is that MOST of the people involved in the "w4r3z" scene are simply couriers, and couldn't hack a program if their life depended on it. But it only takes a few good programmers to crank out cracks for everyone else to use...
Quote:Quote:In fact, I think most debuggers can disassemble a running process.
IF it cracks up... they will catch it at that point & examine it by contents dumping to file or screen...
As I said above, VS can attach to a process without waiting for it to crash...
Quote:There are ones I can sue to this day in fact because I have a patent on the idea... & your reason is really the only one I don't, and the fact that courts are hassles as well.
Most are just small companies or single individuals like myself anyhow, not worth the pursuit of it.
I'm no patent lawyer, but my guess is that if you haven't gone after them by now, an infingement suit probably wouldn't get very far in court...
Quote:I am glad you did, I offer my points in rebuttal. Good discussion, no offense taken here as I am 'drinking in & digesting' your views... they make me think & give me ideas as well.
Intelligent discussion should be cultivated wherever possible... I am convinced that a lot of the ignorant people in this world are that way because they don't try to be better... not because they've got some predisposition towards stupidity. Well, maybe - I don't think even laziness can explain many of the Darwin Awards...
A hex editor is not all that different from a disassembler. If I wanted to, I could take a hex editor and translate each byte into the corresponding op-codes. This is all that a disassembler is doing; it just automates the process...
Quote:Quote:One thing I just thought of, is that Visual Studio's debugger will disassemble a program if the source code is not available. Which means that it obviously has a disassembler... Would your program complain about having VS open?
Nope, I don't watch for that. It is a legit tool as far as I am concerned, but its debugger only activates iirc, if a program crashes & you replaced DrWatson with it.
Not true... I can open up ANY running process simply by going to Tools -> Debug Processes. It will attach to the process, and then I can pause it, browse through the code, and do all the standard debugging stuff. If you have the source code and it was compiled with debugging symbols, then it will show your position in the original source. But even if you don't have the source code and there are no debugging symbols, it will still show you the disassembled code. To test this, I just attached to iexplore.exe and started stepping through the code - not a problem! Of course I have no reason to go wading around through x86 assembly. Ugh! If you've ever developed assembly for any other processor, you'll know how horrid x86 assembly is.
Quote:The main point is, having a debugger around is one thing, knowing how to use it is another... additionally, even if you do, it's NOT all that easy to use to disassemble for a particular branch of code anyhow. With today's code using runtimes &/or .VCL or .OCX & .DLL calls, that code often branches to prebuilt code from the OEM for those things, not code that is unique & written by the developer that is the prize sought by the hacker.
Well hell, if you can't figure out how to use a debugger effectively, then you're not going to get anywhere digging through assembly...
Quote:Still, guys are out there that know how it's done, & have the patience for it. I have had it done is why I protected against it, & saw my work on Wahh-rezz sites in the past enough to know its done... I was using canned shareware protectants back then. They failed me.
My guess is that MOST of the people involved in the "w4r3z" scene are simply couriers, and couldn't hack a program if their life depended on it. But it only takes a few good programmers to crank out cracks for everyone else to use...
Quote:Quote:In fact, I think most debuggers can disassemble a running process.
IF it cracks up... they will catch it at that point & examine it by contents dumping to file or screen...
As I said above, VS can attach to a process without waiting for it to crash...
Quote:There are ones I can sue to this day in fact because I have a patent on the idea... & your reason is really the only one I don't, and the fact that courts are hassles as well.
Most are just small companies or single individuals like myself anyhow, not worth the pursuit of it.
I'm no patent lawyer, but my guess is that if you haven't gone after them by now, an infingement suit probably wouldn't get very far in court...
Quote:I am glad you did, I offer my points in rebuttal. Good discussion, no offense taken here as I am 'drinking in & digesting' your views... they make me think & give me ideas as well.
Intelligent discussion should be cultivated wherever possible... I am convinced that a lot of the ignorant people in this world are that way because they don't try to be better... not because they've got some predisposition towards stupidity. Well, maybe - I don't think even laziness can explain many of the Darwin Awards...
