|
 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
|
|
|
|
|
jhwurmbach wrote: In this case, I would use smart-pointers anyway
Sure. but this introduce a level of indirection that influence the algorithm semantics
(like
for(mylist::iterator i=alist.begin(); i!=alist.end(); ++i) (**i).do_something(.); )
(note there's two "*", so the algorithm where the "for" is, must be designed to track that,
or you've to design algorithms to have an extra "traits" parameter to define how to handle the dereference e the dereferenced type, that list is not directly aware of).
in other words, there is always something missing, whether the approach is.
What we can do is choose what to miss.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
emilio_grv wrote: in other words, there is always something missing, whether the approach is. What we can do is choose what to miss.
There is something deeply philosophical in this words.
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
But yes, you are right: There is no one size fits all - Tool. Which makes much of our qualification.
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
|
|
|
|
|
you're talking about a "type-dependent" type.
Templates are the right way to go.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I wanto an edit box which takes only numbers and special character.
Is there a property that can be set like we have 'numbers' or do i have to make my logic inside?
KIRAN PINJARLA
|
|
|
|
|
A raw sample code for filtering the space may look like...
BOOL CTestDlg::PreTranslateMessage(MSG* pMsg)
{
if( pMsg->message == WM_KEYDOWN )
{
if( pMsg->hwnd == GetDlgItem( IDC_EDIT1 )->m_hWnd )
{
if( pMsg->wParam == VK_SPACE )
{
pMsg->message = WM_NULL;
}
}
}
return CDialog::PreTranslateMessage(pMsg);
}
- NS -
|
|
|
|
|
you do have to write your own logic for that.
i can share it with you if you come back with the actual requirement with an example.
|
|
|
|
|
I have to create login codes which will contain only numbers and special characters like *,#,$,+,-. So i want the edit control to accept only therse characters and numbers.
-- modified at 3:16 Friday 31st August, 2007
KIRAN PINJARLA
|
|
|
|
|
use onchange event of the edit box.
in that box, keep scanning the string available in the edit box.
there if you find any un required character,
simply, update the edit box with a new string, which omits that character.
ultimately, you will get the output as if the un desired characters are not being taken by the control.
-- modified at 3:37 Friday 31st August, 2007
|
|
|
|
|
Windows hooking mechnism may be desired to solve your problem.
|
|
|
|
|
I am afraid that is bulky... since there are simple solutions.
- NS -
|
|
|
|
|
Why?
Wouldn't subclassing be much easier?
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
|
|
|
|
|
kiran.pinjarla wrote: I wanto an edit box which takes only numbers and special character.
You can have a edit box that takes only numbers. No way of inserting "-1.0".
Useless crap. One of the larest omissions in the Windows GUI-classes.
For usable numeric edit fields, scan the "controls"-section of codeproject.
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
|
|
|
|
|
Create a new class with base class CEdit and override the OnChar event handler.
void CharEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)
{
if ( (nChar >= 65 && nChar <= 90) || (nChar >= 97 && nChar <= 122))
{
MessageBeep ( 0 ) ;
return ;
}
CEdit::OnChar(nChar, nRepCnt, nFlags);
}
Thats it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
