|
thank you
how to retrieve it.
|
|
|
|
|
See GetVolumeInformation
- NS -
|
|
|
|
|
It isn't 'Unique' ... it can be changed formatting the HDD, or programmatically
Russell
|
|
|
|
|
That's true. But it can be considered as unique, for creating software licenses.
- NS -
|
|
|
|
|
This is unwise as any change to that volume would render the app un-runnable. There are any number of ways in which this ID could be changed. If you intend to use any ID from a PC, always take it from a physical item.
|
|
|
|
|
HDD ID was used for this purpose when I was coding for DOS applications (many years before). May be due to that my first choice is HDD. 
I have no idea whether the mother board ID, etc is available at that time. Do you have any knowledge regarding this?
- NS -
|
|
|
|
|
Of course you can,
but we not need to be an expert haeker to crack your license: buy one licence and run the software on other PCs simply using this[^]
Russell
|
|
|
|
|
Yes...
So you say, we should not use it?
- NS -
|
|
|
|
|
You can use it...but don't tell you are doing that.
The best is to mix that ID with other information like CPU ID, motherboard, ...
But comes other problems: not every CPU has got the ID 
At the end I think that I sure way is doesn't exist
Russell
|
|
|
|
|
_Russell_ wrote: But comes other problems: not every CPU has got the ID
HDD is anyway, reliable... 
For complication, I used to use HDD ID combined with user name, etc. 
- NS -
|
|
|
|
|
NS17 wrote: HDD is anyway, reliable...
There are exceptions also there
we can ask suggestions on the "lounge" ... but I think that it will not be the first time...and I dubt that it is possible to have a solution.
We use USB Dongles ... they are unique, ... but I prefere software ways
Russell
|
|
|
|
|
_Russell_ wrote: I prefere software
I like cracking... but dont tell anyone... 
- NS -
|
|
|
|
|
|
 Ooops
- NS -
|
|
|
|
|
There is no unique ID for a computer. The closest you will get is by getting the ID's for things like HD, CPU, BIOS... and combining them in some way. Even then, it will not be unique and you will have problems when a user decides to upgrade one of those components.
BTW. This is similar to how windows verification works.
[ Appended ]
As an afterthought, you could possibly create a GUID and combine it with one/all of the above items.
|
|
|
|
|
But for protecting a software from piracy, these are very helpful. Am I right?
- NS -
|
|
|
|
|
Not really, infact it would create more hassle on your part.
Using your aproach you would have to get these ID's and create some type of key which the user would then have to send to the distributer who would then have to run it through a keygen who would then have to send back to the user. Then the software needs to have the same keygen algorithm to verify the new key.
With this in mind, a hacker could decompile your exe, extract this algorithm and create his own key generator.
There is no real answer to piracy, all you can do is make it more difficult.
Look at things like PE compression/encryption. And make any keygen algorithms as difficult as you can.
|
|
|
|
|
WalderMort wrote: There is no real answer to piracy, all you can do is make it more difficult.
Yes I agree. I just intended to say that we can considerably reduce the risk than creating a software without any protection.
- NS -
|
|
|
|
|
To protect your code you can also use hardware USB drivers, we use they, ... but I don't know if they are easily crackable.
Russell
|
|
|
|
|
I suggest you to take motherboard identification because the other components are upgradeable like HDD etc...
You can use WMI to get these information ( e.g for motherboard serial is retrieve information using "Win32_BaseBoard" class.)
As someone else posted previous, it's better to combine some asset id rather than depending on single entity.
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
Problem:
I run across a problem, briefly, following the concept that a Linked List is a Collection
of some kind, that is to say, a LinkedList class is derived from a Collection class.
Which interfaces should a Collection provide?
Having read some articles about this, conceptually, I though it should provide:
- Insert(basic);
- Add(extensive);
- Append(alias of Add);
- AppendFirst(extensive);
- AppendLast(extensive);
- Remove;
- Clear;
- Contains;
- Capacity;
- Size(optional, actual size in byte);
Back to paper, a linked list should inherit from a collection, that is, all operations
above should be available to the list. But I cannot predict the way a collection stores
its items, dramatically this happens to be the functionality that should be provided by
a linked list, because I consider that a linked list only provides a way to store data.
So there's no way to implement a Collection class without introducting a way to store
data.
One way to follow the concept I metioned above is to make a collection an interface,
that is, the provision of its operations has no implementation, the definition of them
will be given by other classes by which it is inherited. But there's still the problem
unsolved - the operations' prototype are inconsistent, for example:
class ICollection {
public :
/**
* I have to declare the parameter pItem as of type void*.
*/
bool Insert(void *pItem);
};
/**
* Linked List node, the management unit basis of the linked list.
*/
struct ListNode {
};
class LinkedList : public ICollection {
};
/**
* I have to implement the base class's Insert operation which
* takes an undesired parameter that I want it to be replaced
* by ListNode*.
* Otherwise the introduction of ICollection becomes unnecessary.
*/
bool LinkedList::Insert(void *pItem)
{
return (false);
}
The base class's Insert operation is still unnecessary, because
its parameter pItem of type void* is not what I need, I want it to be
of type struct ListNode* instead, but here overloading the operation
makes no sense at least for me.
Had I made the LinkedList a base class of a Collection, I consider it
makes sense because LinkedList provides a mechnism of storing data,
a Collection is in need of this mechnism.
Question:
Is there a way to make a LinkedList a base class of Collection without
breaking the concept that a linked list is some kind of collection.
using namespace System::ComputerCrashArt;
-- modified at 3:15 Friday 31st August, 2007
|
|
|
|
|
Wow that's quite a reflection
And, using the list class from the STL (standard template library) isn't that a LOT more easier than redevelopping your own ?
If you still want to develop your own, I think you definitively have to look at templates.
|
|
|
|
|
6Qing88 wrote: I run across a problem, briefly, following the concept that a Linked List is a Collection
of some kind, that is to say, a LinkedList class is derived from a Collection class.
The STL-designers did deliberatly do without a common base class/interface of all STL-collections.
They have, instead devised certain concepts or aspects, which an STL-container "models".
So, a set is a model of "associative container" - without inheriting any interface.
6Qing88 wrote: bool Insert(void *pItem);
Here, templates seem to be the wapon of choice.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
jhwurmbach wrote: without inheriting any interface
That's not proper.
They don't inherit by class inheritance, but they all "inherit" (make use of)a same "interface" (set of public methods) from a common "model" (not a C++ concept, but an abstract concept) so that a generic algorithm can invoke them regardless of the kind of collection you are using. Unless your dealing with specific method not supported by all the collection types.
Template generic programming don't inherits function from the bottom, but construct it on top. But always "inheritance" (in plain English) is.
An "idiot" append algorithm like
template<clas A, class C>
void add(const A& item, C& collection)
{ collection.push_back(item); }
works the same for vector, list, deque, stack.
And does'nt compile for collection that don't support push_back or if you try it with not properly related A and C.
Unfortunately for STL, in all the cases where value semantics is not desirable (i.e: A is a huge structure you don't want to continuously copy), or when classic C++ inheritance is needed, (you need proper translation units, not template instantiation) its not the way to go...
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
You are right, in an implicit, conceptual way, the STL *uses* ihheritance. Or rather common concepts implemented in differnet classes - like iterators.
But it does not use inheritance in the C++-sense, which was the point to make to the OP.
emilio_grv wrote: Unfortunately for STL, in all the cases where value semantics is not desirable (i.e: A is a huge structure you don't want to continuously copy),
In this case, I would use smart-pointers anyway. Preferably in some Interface-based-programming-style.
emilio_grv wrote: or when classic C++ inheritance is needed, (you need proper translation units, not template instantiation)
Yes - STL-containers in module interfaces are very tricky. E.G. in a DLL-interface: sometimes it works, sometimes not.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
