Related
guys, I'm not sure the title is correct on my real problem. I am now having a requirement to deliver one windows installer which should contains all features or functionalities, but the customers can only install a sub set of the features or functionalities based on which he buys. And it also allows him to buy more features (or functionalities) if he pays.
I am using wixtoolset to create the kit. However, the term 'feature' I used above does not necessarily mean the term "feature" in wixtoolset context. I just don't know how to describe my requirement more precisely.
The reason is, the software we are developing actually provide many functionalities, but different customers don't want all of them, so this would be a way for them to save money. We cannot deliver specific features/functionalies for different customers otherwise it'll be a nightmare for us to manage.
I would appreciate if anybody could assist.
I am new to programming, and just have wandered a few minutes with NFC. And I need to program an attendance management software by using the input of NFC tags in a reader for a school project. I just downloaded the Gototags Windows software for encoding, but I can adapt to any other software you know can do this task.
I’ve only been wandering around for a few minutes, and saw a tutorial.
I vaguely know there should be a way to do this through excel but I don’t even know how to open excel through the gototags app
As it is only a school project I don’t expect nothing more ambitious than a database that keeps the number of days certain person attended and showing the name of the person.
This is really basic stuff but you need to make things clear in your mind. And since you are new to NFC AND programming, you'll be passing through a long research step.
If you intend to program your own user interface with your own features and stuff, you have to choose a technology to program it.
I don't know GoToTags but it seems to be a simple program to encode chips.
It writes on it and that's all it does.
There is nothing that allows you to read a chip, write the results in a database or display them in a custom interface. Which is what you gotta do, right ?
It appears they had an SDK for .NET but i didn't find anything else than an error 404 on their website...
Once you have your technology, you can start to search for more accurate informations on how you can do it and split the work into multiple steps.
Basically,
The basics of this programming language
How can i create a database and access it through my program
How can i read a chip and 'send' the data into my program (it has to be compatible with the programming language you previously choosed).
You also gonna need some hardware. Do you have anything given or imposed by your school ?
Once you have all of this, all the work is done :
Read the chip data.
In database, access to the user related with the data you read (every chip got an unique ID, you could use this UID to 'link' each chip with the users in database)
Verify this is the first attendance of the day for this user
If so, increase by one the number of days attended in the database and/or display the new number on your software interface or whatever else you chose to give a visual feedback.
That's all. Then, if you got time, you can add several things to your program like an auto-enrollment for users and the chips. But it already fulfill your expectations for this project.
If you have any question/additional information to give, we can discuss it. I wrote this as an answer because i don't have enough space to make it a comment.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I asked a question about a good book for this topic.
It's not getting many replies, so maybe there aren't any good books (although I find that strange; I must go search Amazon for myself).
In the absence of a book, maybe there is a good framework, some good URLs, or just general advice.
As I asked in the other question:
I am looking at several projects, all
with roughly the same functionality.
Some instruments collect some data (or
control some functionality). They
communicate by Internet
(Ethernet/wifi/GPRS/satellite) with
a database server which stores the
measurements and provides a browser
based means of querying the data,
producing reports, etc (and possibly
also allows control of the remote
equipment).
Can anyone recommend a good book
describing an approach to developing
such a software architecture, keeping
it generic, which tools, languages.
test methods, etc to use?
For "book", please substitute "framework, some good URLs, or just general advice".
This is a very common system pattern. Who can advise?
I have written a complete SCADA system (excluding the custom instrumentation hardware). The system was designed to be generic to allow the creation of new hardware models, instruments, and data collection - it was not written like so many SCADA systems for an individual company/plant but is used internationally for thousands of companies/plants.
I was the sole developer/designer with one member of management overseeing and guiding the project. It took longer that way, but it was doable. We looked at other SCADA specific systems/frameworks already out there and decided that since our units were custom, it would be easier and more flexible to write the system from scratch leveraging existing development frameworks and 3rd party components. Looking back, this worked out really well for us because we had the time and skill, but this is generally not the best solution depending on your business/contract model.
I am no longer with that company, however, they still use my software exclusively and I left on excellent terms. I would be happy to answer any general questions you have and to help point you in the right direction.
System Architecture
Here is a high-level overview of what the system consisted of:
Custom Cellular devices that had generic inputs to accommodate multiple instruments of varying types (analog, digital, pressure, amperage, floats, etc.)
UDP/TCP packets of custom format were sent by the units across the cell network (GPRS) to our servers (Windows Server 2003 R2). Information was sent regularly for reporting, and on customizable state changes that could be programmed at the device or online (the configuration sent over the cell network).
A custom Multi-threaded .NET application using TCP/UDP Listeners that grabbed incoming packets (Several Hundred-thousand a day), deciphered custom headers, and routed the packets without further interpretation to the correct database (Some clients required their own standalone system)
A Microsoft SQL 2005 database that acted as the brain for the entire system. Packets were interpreted using CLR functions and automatically triggered alarms (as configured), compiled reports, and kept a full history
A custom .NET application to handle alerts by placing phone calls, sending SMS messages, and sending emails. The phone logic was handled by an Intel Dialogic Card over analog lines using a combination of recorded prompts and Text-To-Speech.
3 ASP.NET sites:
Customer facing site that allowed them to manage their accounts/sub users, track alerts, configure units and alerts, chart data, map devices, export reports, etc.
Sales site that allowed the distribution of material to sales people, tracking of individual devices, device health reporting, etc.
Internal management site that allowed the creation of customer accounts, the configuration/build of units, and all other administrative features as required.
There was also a custom internal monitoring system to verify the health of the system and to alert technicians of problems as necessary since the system needed 24/7 uptime.
In addition we created an iOS app, a mobile site, and a custom web service/client (API) to allow the retrieval of customer data directly by customers to allow them to integrate our solution with their existing (usually custom) SCADA systems.
Those are the components we used and they worked. Doing it again I would change a couple of things. I would use Windows Server 2008 R2, SQL 2008 R2, and instead of a Dialogic card I would use Microsoft TellMe using VoIP. I would also use Silverlight instead of ASP.NET. I really like ASP.NET, but Silverlight can give a much better presentation and can be used outside of the browser as necessary - a common request from SCADA operators.
The sites all used 3rd party components so that charting, and tables didn't have to be written from scratch. There are some SCADA specific components (largely Java based) out there. However, we found most of them to be crude, ugly, or way too specific to be used in our generic system (also expensive! It was easier and more flexible to customize a gauge/charting package to "make" our own).
As mentioned, the brain of the system was the database. This was done because Microsoft SQL is a pretty awesome, well supported product designed for extreme uptimes with great backup and performance options. We were also really impressed with the .NET CLR integration that was possible allowing our custom .NET code to run as a part of that process. The units we were supporting came in a variety of models and could be configured to use any combination of instruments and so keeping the database flexible was key. We used a lot of normalization!
One thing that really helped was to use Recursive CTEs to fake the existence of data when the values were still the default. We did this to save space in the database, but this also enabled us to introduce a layer of abstraction in the database that allowed the queries to be flexible as well.
We had messed with OPC in the past but found it too inflexible, difficult, and irritating for our needs. That was a few years ago though, and I haven't looked at it since.
That is a long and very general answer to your question. I can't give you specific code or go into extreme detail since that information is property of that company, but I can answer some design questions and point you towards frameworks/tools we found helpful. My main advice would be to break everything down into separate components and employ the black box model on each so that individual components can be swapped out/improved as necessary. The scope of the project can seem overwhelming otherwise. Let me know if you have further questions or would like more information, good luck!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We plan to sell a Windows portable application. By 'portable' I mean that it can be run from any Windows computer without installing it. For example from an USB stick etc. However the application while (theoretically) it can work anywhere, is targeted to LAN environments.
What solutions do you see that while keeping this advantage (in a more or a lesser degree) to still make money from it?
PS: The application is/will be written in Delphi.
If you are offering your product for sale and not for free, then you will most likely make money from it. If what you are asking is how to maximize the income and prevent piracy, then that is a more specific question.
The key to making money with software is to make the purchase route less painful then the piracy route. Usually the biggest hurdle to purchasing software is the price tag (but not always, some people just will never buy software and always pirate, but you can't do anything about that). And the biggest hurdle to piracy is some sort of DRM scheme, which is actually the second largest hurdle to purchasing software. Often times DRM only annoys the legitimate purchases, while the pirated version has all the DRM removed with less effort then you spend to put it in. Thanks to the wonder of electronic duplication, once the DRM is removed, then everyone can have a DRM free copy.
So you want a solution that only annoys illegitimate usage, but not legitimate purchases. This is much harder to do then expected.
Depending on the price tag for your software you might consider deploying it on a keyed USB drive (i.e. Dongle or USB stick with some special key). Then it is portable, but only on the hardware you provide. The user never has to worry about a secondary authentication scheme, and the DRM only becomes an issue when the hardware (which is harder to duplicate) is changed.
You say that it is only for a LAN environment, which doesn't necessarily mean that the computers will have internet access (and if they do, they probably have a proxy requirement) which means "phoning home" will be problematic. If you want the product to only be used on a specific LAN then you might require a license server to be installed on the LAN. Then the software could always check with the license server to make sure it is authorized. That won't work if you want it to run on multiple LAN's though.
Conversely if your price is low enough then most companies and people would rather buy the correct licenses and not risk the piracy. In actuality, depending on your clientele, most people will prefer legitimate licenses when they can, and DRM can actually discourage them from buying licenses.
Some alternatives:
Use a dongle, where the user of the software must plug in the dongle before your application can work.
At startup read a configuration file and if this is invalid or missing, halt the application or reduce its functionality. The configuration file should contain information about the user or company that licensed your software, and also a checksum to prevent users from changing the file. With such a file, serious companies are less likely to distribute this configuration files to others. Of course, you should then create one such configuration file per user that licenses your software.
Optionally, include specific computer information (type, memory, bios date, system guid, ...) that prevents the application from being run on other computers.
Make sure you make money from the service you can deliver, not only from the software you are selling. This service can include: providing upgrades, taking suggestions for improvements, assisting with problems, helping with domain-specific knowledge, ...
You can use some sort of license file and a "phone home" option that makes sure the same license is not used at more than one place concurrently.
If you have a large ordfer, you could try to get a memory stick with a special serial number and/or value in it that you can read out in the software (eg the exe must reside on a special memory stick)
Please note that a lot of users get quite annoyed by these things (we've used the first option)
Also please note that if commercially interesting, your app will be hacked. Make sure the effort someone has to take outweighs the profit the could make
One approach that also helps some is by custom branding. Each copy you sell would have compiled into it the name of the company it was sold too, which can be displayed as part of the splash screen as well as the about screen (along with a button to view the license terms). Most often this branding is done by using an external file which contains the information encrypted that when placed in the same directory as the executable is used to unlock the application as well as possibly provide additional functionality.
Unfortunately with todays software firewalls, most of the simple solutions to disallow running multiple copies on a network are not practical while still maintaining true portability, or requiring internet access to a server that you fully control.
Yes, piracy is a problem, but if you continue to offer great support and there is an additional "visible" benefit to purchasing, you can help offset this in your favor.
If you need trial protection, you can count uses/days if you have any sort of database where the user will have invested time and data, and won't want to lose it. Just encrypt the counter and place in the database somwhere. The user can then only reset the trial by wiping out the database. Depending on the type of app, this may be effective, or not.
Another approach is to not have a portable trial at all, but offer it as an incentive for purchase. i.e. conduct the trial on the desktop, and when they purchase a license, they get a license key that allows it to run on portable devices.
I recommend the PortableApps.Com framework for launching your app. It's free. You need to make your "launcher" open-source, but not your app itself. You can still run on a bare drive, if you follow their pattern.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am thinking of implementing a good licensing mechanism that has a good resistance against piracy. The required mechanism should not use an internet connection at each and every time the software is used. I am thinking of a mechanism based on hardware IDs etc. Do you guys have any better suggestions? What are the parameters/algorithms/characteristics that I need to concern to make a hack proof license mechanism?
Ideally you need something that is OS independent.
I would recommend that you embed the license protection within your code or wrap your application within it in such a way that it cannot be run without the copy protection code having run first.
It would be best if your application needs a license key file in order to operate and that this isn't generated locally.
One way of doing this is that your application generates some form of image code based upon the hardware on it's initial run. This is supplied to you and in return you supply the license key which will allow the code to run. Best to base the hardware image around CPU and motherboard as these will change the least often.
Your app. should check against hardware image and license key whenever it is run.
If you want your app. license time limited then it should also keep track of how long it has run and embed it within the license key file.
Don't forget to encrypt the license file.
Also don't forget to make it more difficult to reverse compile your executable by use of a dotfuscator or similar.
Check this question: What copy protection technique do you use?
It also links to other related questions.
First of all, nothing is hackproof, so i wouldn't spend too much time on protecting your software.
The downside of a mechanism based on hardware IDs is when a user buys a new computer or upgrades most of his computer he needs to update the key too.
HWHash is a pretty good HardwareID implementation, but i guess there are more (free) solutions.
At work we use Hardlock and Hasp keys, but these are usbkey solutions which are not very efficient for small applications.
I am thinking of implementing a good licensing mechanism that has a good resistance against piracy. The required mechanism should not use an internet connection at each and every time the software is used.
Then how about a periodic online check of the licence?
When the user logs in the first time, the user verifies the install against his account and a licence file is stored on the users PC. This licence file is encrypted and contains all the data needed to uniquely identify the license. This is all stored on your server.
The licence file expires in set number of days or even months. Logging in after the file expires checks against the account and verifies its legitimacy. You might even consider generating a new licence file at this time.
There should be some smarts that give some leeway in the case that the users internet is down and the licence cannot be registered. Perhaps 7 days.
If the software is reinstalled on a new computer the user has to repeat the verification process.
As the others have stated there is no way to beat a determined pirate, since such a person will hack the code, but this should prevent or slow down casual piracy.
You can check out Microsoft's SLP - I haven't used it, but it definitely looks interesting (yknow, IF you're into MS stuff...)
One important point to note - no licensing mechanism will protect you from piracy, or even substantially reduce it. By definition, the licensing mechanism will be client-side - which is inherently breakable. Take a look at all what happened with DRM...
Your guideline should therefore be usability - the intent should be to use it as a general policy, the good guys will be comfortably limited to what they're supposed to be allowed to do, and the bad guys - well, the bad guys will get around your intent anyway, your best hope is to make it more work.
I'd be very wary of published software protection mechanisms, as they are much more likely to have published hacks. You are probably better off using some of the techniques to get a unique persistent ID and use this to roll your own protection mechanism. I also think that it is a poor idea to simple check the license whenever you run the program, as this leads the hacker to the location of your proection mechanism. IMO, your are better checking the license in a more random fashion, and more than once per session.
FWIW, I use hardware locks (hasp) for my high end desktop software, and device ID based licensing on mobile solutions. If you are selling small quantities of high cost software in a vertical market, IMHO, a good license protection mechanism makes sense, and hardware dongles work well. My experience has been that people will use more licenses than they purchase if this is not in place. For high volume, low cost software, I'd tend to live with the piracy based on increasing the size of the user base and product visibility.