Is there any unique computer ID that distinguishes a computer from other, like finger prints for human?
If yes, please advise how to get it in vb.net.
It is possible to put together info to uniquely identify a machine. This has already been done by many software vendors, most notably the Microsoft Activation service does it by sampling various bits of hardware on your system. The problem with this approach is that the identifier is not guaranteed to be persistent.
What i mean by this is:
the chances of another computer co-incidentally having the same identifiers is nil
if it becomes public knowledge which identifiers you are using it would be reasonably easy to spoof the identity of a machine
the identifiers can change over time as users change hardware, so the "fingerprint" will also change
For further reference, try these links:
Previous SO question: What's a good way to uniquely identify a computer?
MSDN forums: Uniquely identify computer
Just remember: the more points of reference you use to assemble your identifier, the greater the chance it may change at some point in time.
Try getting MAC + CPU ID + Motherboard serial. If you concatenate these then its you unique finger print of that machine until hardware changes occur.
Bear in mind, many people these days are working with dual operating systems (eg VirtualBox) and the MAC will be different. Even swapping network connectivity (ethernet hardwire vs wifi) will change the MAC. I would say MAC is not a good reference for identification.
Well it can be done in many ways.
You can try to get all kind of data about the computer, and then hash it to a string that will identify it. For example, number of drives, number of processors, the user's name, some keys in the registry.
But you have to make sure all the data you take is data that doesn't usually change.
Related
I've got various settings that need to be looked up and stored according to various parameters.
For example, I need to know the hardware settings, which depend on the computer being used and the type of device connected to the computer.
I need to know which the procedures to run, which depend on the device connected to the computer and the type of session.
I need to know how to process the data, which depends on the device, the type of session, and the computer.
Setting (Item that can be looked up)
Parameter (what the setting depends on)
hardware settings
device, computer
procedures
device, session type
data processing
device, computer, session type
In reality there are a lot more settings, and there are potentially more parameters that they would depend on, but the concept is this: there is some mix and match of parameters that can be used to look up settings.
This following is the obvious (and in my eyes naive) solution. Only relevant columns have been included:
This has various problems:
Adding a new parameter requires all settings relevant tables to be updated.
Lots of duplication of columns (e.g. lots of tables will have a DeviceId column and a SessionTypeId column)
My thinking is this: Why not wrap the parameters into a single table? Then settings can point to the wrapper table. If the settings don't depend on all the parameters they can point to wrapper records where the parameter is NULL:
Is there anything inherently problematic about this revised schema? What are the pros and cons of each approach? Which schema would you be more likely to use and why?
Thanks!
This may be a case for the KISS principle.
Only dozens or hundreds of devices, computers, procs, etc? Skip the ids. Simply use the unique name you already have for them.
Then, it might be simply one table with three columns:
The computer/device/whatever
Whether the value is a size/proc/etc
The value/name/etc of one size/proc/etc.
Numbers can simply be stored as strings (VARCHAR(191)) so that there are no typing problems. The program reading, say, a numeric "size", can simply treat the result as a number.
If one computer is allowed to run 3 procedures, then there would be 3 rows for that.
I have an 8 bit digital output board used for device controlling. Each external device needs one bit and is controlled by a different application.
I have written a class library and the class DigitalOutputPort (VB 2010) that envelopes the driver that manages the 8 bit port. Each device application uses this class, creating its own instance.
In order to set a bit of the digital output port, I have to write a byte to that port: this byte is the bit mask for all 8 bits together: to set HIGH the bit number 0 - 1 - 2, I have to write 7 on the port, to set HIGH all 8 bits, I have to write 256, and so on...
All works fine when only ONE application uses the class. But if two applications want to set its own bit on that port, I get problems because I do not know the current value of all bits set by other applications (the driver has not such function) and, of course, I cannot change one bit without changing all the other (if I do not know the current bit mask)
Normally this looks like a typical case of sharing data between two application and my first idea was to write the current value of the port in a file on the disc, where all application can access and read it. But it seems to be too much heavy for this simple problem. Moreover it could also creates performance ans reliability problem.
Then I though about using a shared field (property) in the class. A shared field preserves its value between all instances of a class: but is it also true between instances from different applications? I cannot find more info about this last point, I have to make same test.
A third way would be that I create just only ONE instance of the class DigitalOutputPort, one for all applications.
The first application that needs it, create the object, all other applications will used the already created object.
I like more than other this way, but I do not know if and how it can be done.
Which should be the right approach in your opinion?
Thank you for replying.
Two different applications will always have distinct and separate memory. So even a Shared field will not be the same. A Shared field is shared only in the context of a specific application and its memory, not globally on the system.
So you need to share data between two applications. There are several options, though the simplest and easiest is the one you mentioned - store it in a file on disk. It's not overkill, since it's a very simple implementation. Just remember not to keep a lock on the file, since several processes will need to access it.
Another possibility you've raised is with a shared instance of DigitalOutputPort. This means having the first application create the instance, and expose it via WCF/Remoting/some other cross-process communication method so that other apps will access it. It's certainly possible (though the state of the DigitalOutputPort will be lost once all of these apps are closed), but it's a lot more complicated, especially if you don't already work with these communication frameworks.
I'd stick to a file on disk, or perhaps a registry key, to store shared, persistent data between applications.
I am doing this for the first time, how do I use SQL via vb.net to insert, update and delete data in the database. Do I need to set up anything before I can use SQL? If I shift my executable app to a different computer do I need to install SQL in that computer as well?
There are a number of tutorials which can get you started.
As for running the applications on a different computer, it depends on where the database is located. Generally the database and the application are two separate things, the latter is simply accessing the former. Can the other target computer also access the database? Will the database be installed on a server accessible to the target machine? As long as it can see the database and its config file is correct, it should work fine.
This question is pretty broad. It's like asking "How do I drive a vehicle?" There are many different types of vehicles: boats, cars, rockets, airplanes, skateboards, etc. To tell you how to drive a vehicle we need to know what type of vehicle you want (or at least whether or not it's a land vehicle, water vehicle, etc). Likewise, there are many different ways to "use SQL via vb.net". Do you want to do Web development, standard Windows apps, console apps, WPF?
The best starting point is probably to learn pure ADO.NET since all of the other methods are built on top of it. Learn the basics before getting into LINQ, Entity Framework, etc.
I'd start here: http://www.csharp-station.com/Tutorials/AdoDotNet/Lesson01.aspx
What is the purpose of GUIDs in COM?
Is it only to avoid name conflicts?
It serves the exact same purpose as a name. A COM client can ask the system to create a COM object using a simple identifier (CoCreateInstance). That identifier has the scope of the full machine. Different chunks of code written by programmers that don't know each other and work for different companies live at that scope.
The problem with names is that people suck at picking good names. The odds that one programmer picks the exact same name as another programmer, 3000 miles away and 5 years ago are high. Names like "Record", "Database" etc would be popular choices. Evident at this website too, lot's of users named "Jason" or "Mike". They don't mind, they know their own name when they review their profile. Context. Impossible for me to find them back though when they send me an email with just their user name, following up on a question with a generic subject string.
Getting a name collision and COM creating the wrong object is disastrous. The program stops working because it is getting a completely wrong object. Finding out why is difficult, the error message sucks. Actually fixing the problem is impossible. Calling programmer B and ask him in the friendliest possible way to "pick a different name, somebody already picked yours" doesn't work. Automatic response is "call programmer A instead".
This is not a problem when you use a GUID instead of a name. They are Globally Unique IDs. The odds of getting a collision are astronomically small.
Probably, as it would guarantee a globally unique identifier for each object.
As the name suggests, it's an identifier and serves the same purpose as any other identifier. As you mentioned, avoiding name conflicts is one use. Another advantage is that it is only 128 bits long (as compared to a name which could be arbitrarily long) so comparing two GUIDs is much faster than comparing their corresponding names.
As it name suggests, GUID is a globally unique identifier. Which means that if one developer generates two GUIDs he gets two different GUIDs and if two developers who don't even know about each other generate one GUID each - either at the same moment or at different moments - they again get two different GUIDs.
Now consider a problem - any developer needs an ability to introduce new interfaces and classes and make them uniquely identifiable. That's because if you get an interface pointer and your program treats it as some InterfaceA* but it really is not an InterfaceA* you've got a major problem - your program runs into undefined behavior - crashes or produces unexpected results.
The above problem is easily solved with GUIDs. Every developer creates a new (and thus unique) GUID value for every new interface or class he introduces. This is reliable and convenient (except that GUIDs are not that human-readable).
PC keyboards weren't designed for gaming, compromises were made to bring the price down, so some problems occur. Most importantly, when you hold down certain keycombos, some keys don't react to pressing.
My game has two users at the same PC control two characters in realtime (i.e. not turn based). An instance of the problem: player 1 holds Up and Left to go in that diagonal direction. Player 2 is then unable to go to the right (with "D"). Beyond being merely annoying, it can give an unfair advantage to a player who opts to use the bug as a cheat. Not fun :(
The basic commands are: shooting, walking left and right, and jumping. Shooting is done with LeftControl and RightControl, which don't conflict with anything, so let's consider only the movement keys.
On my laptop, most obvious keybinding combinations fail:
WAD and arrow keys fails with Up+Left+S and Up+Left+D
IJL and arrow keys fails with Down+Right+J (though Down is technically unused, a player often holds it down anyway)
arrow keys and numpad keys fail with Down+Left+NumpadLeft
all-letter combos like WAD and IJL tend to work, but I don't like leaving the arrowkeys unused, and crowding the users' hands together.
Is there a website that list statistics of common supported keycombos on various keyboards, to help me make my decision for defaults? (they're configurable, but defaults matter.) I seem to recall a relevant site called keyboardssuck.com, but I can't find it now.
How have you dealt with this problem? Just ignored it?
Does the problem depend on the OS, the API, the mobo? On anything else? I think it only depends on the keyboard model, but gotta ask.
edit: Now I know what this is called: "rollover"
The best bet is probably to let the user choose his own keybindings.
This is a hardware-implementation issue. To me this problem presented itself as depending on
how the keyboard is wired internally.
To me it seemed to be like theres no real standard to this. A certain combination of 4 keys
at the same time worked fine on one computer (a desktop-machine) - another keyboard simply
could recognize no more than 3 of those. (laptop)
My hunch is that you can rely on all of the control-keys (ctrl,alt,shift,windows,apple-keys) because they are probably wired on another "layer". But when it comes to "normal" keys including cursor keys, numpad keys and the likes, i would say that you can probably rely on 3 keys at the same time.