I just downloaded Embarcadero Delphi 2010 (the trial version).
tasm32 and the related stuffs (ilink32, implib, impdef, etc) are still available in it.
Still they lack header files and import libs, but fortunately that can be solved by win2inc, implib, etc.
The final result can be called TASM32 SDK (in a similar way like MASM32 SDK do).
Considering Delphi is a commercial product, I plan to use this SDK for personal usage only (and of course non commercially).
Is this legal or not?
"Is this legal or not?"
That depends on the country.
Also, "legality" doesn't have a binary yes/no value (instead the result may depend on arguments made in a court of law, if the question ever even goes to court).
Related
OSX has functionality not available in the iOS SDK, and occasionally I'll find an answer like this one: no route.h on the iPhone SDK, that says "just copy the header file from the Simulator (or OSX) SDK and it'll work fine."
That seems suspect to me on multiple levels, including App Store approval, but then I read something like this from an Apple employee who says "if you're using sys/route.h declarations on iOS for an App Store app, please get in touch with me...", which sounds like tacit approval (or a ruse to catch misbehavior :)
Anyone know where the official line really is, and whether something like this is at all safe to do in production code? I'm particularly interested in lower-level BSD functions and whatnot for portability, as opposed to undocumented Objective-C methods.
I would not regard that comment on the Apple forums as tacit approval. It sounds like they're just trying to decide if some additional BSD APIs should be added for use in iOS apps.
In general, if there isn't an iOS header available for a function, then it's considered a Private API (for example, something under https://developer.apple.com/library/ios/). The official policy on Private APIs is that they're not to be used in apps distributed through the App Store.
Now, you can certainly use them for personal/hobby apps, or apps that you deploy in-house (Enterprise Distribution).
If the APIs you're talking about are APIs that are publically documented for OS X, and you can get them to work for iOS by copying headers, then they're probably part of the Darwin source base. It's very likely that they'll continue to function in future versions of iOS, although that's not guaranteed. Of course, nothing is guaranteed (really), as public APIs get deprecated, too.
Then, there's the issue that not all review checks are automated (I don't work for Apple, but can deduce this from things I've seen get through review). It isn't that unusual for apps to be approved with Private API usage, although if they get popular, Apple frequently pulls those apps from the store within a couple weeks. The review process isn't perfect.
So, my answer is that if you're submitting to the app store, don't expect copying in headers to work.
P.S. If you can tell us specifically which BSD function you're referring to, we might be able to give you a better answer.
P.P.S. The answer you link to about Route.h is from Grant Paul, who writes quite a bit of non-App Store software.
Additional useful information on Private APIs and the App Store
Apple never knows what header files you use - the danger of course is the definition from the copied file is close to, but not exactly, what iOS uses. If this file is important, or a few select files, post a question on Apple's internal forums and you will surely get an answer to such a question. Failing that, burn a DTS incident (you get two a year, I almost never use mine).
I am looking for SDKs which can do finger print matching. Rest of my code is mostly in C so I prefer if the SDK has C API's. Also it would be great if the SDK is free. Does anybody has experience with these SDKs and recommend any particular SDK? Also, while looking in these SDK what are the important features I should concentrate?
I've used two SDKs in the past, but only as a C# developer. Both the SDKs below say that they support C:
Griaule Fingerprint SDK (requires paid-for license)
Digital Persona OneTouch (free sdk)
A quick summary of features to consider:
Are you verifying that a fingerprint matches that of a known user, or identifying a user from a single fingerprint?
The Griaule SDK implements both Verify and Identify patterns.
DigitalPersona's free SDK only supports Verify - to Identify, you have to loop through all the fingerprints in your database and see which one matches best. They state that this is 'inefficient', but if you have very few users (< 200), it seems quick enough.
Adjustment of discrimination sensitivity (false positives/false negatives)
Balance up how closely a print must be identified. A high sensitity may cause a legitimate user's prints to be rejected, but a low sensitivity may match one users' prints to the wrong user. Assess the impact of each case and code accordingly.
The deployment overheads differed - the DP components came with a merge module, but I only recall seeing standalone installs for Griaule.
What fingerprint capture devices are you intending to support? Check very carefully that the SDK will support yours!
Check the licensing terms very carefully the Griaule costs can be substantial based on the number of clients you expect to roll out to.
The Griaule SDK required a license file be deployed, both on client and server.
DP (free edition) did not.
The .NET DP SDK came with a visually pretty, and easy to use, fingerprint registration dialog, but the version I downloaded (v1.4.0) had a bug with the fingerprint capture component taking up to 10 seconds to initialise. I don't know if this has been resolved yet. However, it was straightforward to code a bespoke UI.
Overall, I favoured the DP SDK, but it was a close-run thing. Basically, being license-free and better documented suited me more.
You can use Innovatrics IDKit PC SDK. You can get a free version for 6 months. This provides a C API as well as a C# API. I have been extremely impressed with this package.
If your platform is not a PC, there are packages for other platforms as well.
This is very useful with detail information about fingerprint integration with windows based software: http://www.codeproject.com/Articles/38881/Fingerprint-Reader-Integration-using-the-M-SYS-SDK This integration was using this fingerprint sdk. It solves problems with low level free sdks and also supports other biometric modality.
This is a really simple question, but the answer is really complicated. Most of the Free or at least royalty free matching SDKs are tied to a vendors fingerprint scanner. If you are wanting to use one of those SDKs you will have to commit to their scanners.
The next question is how is the software going to be used. Fingerprint matcher tend to fall into one of two categories, 1 to 1 or 1 to N. 1 to 1 is assuming you know who the user is and you want to just VERIFY their identity with a fingerprint. 1 to N searches through a database of users and finds them by their fingerprint. Depending on the size of your user population, if you are doing 1 to N you may need to confirm the performance of the algorithm first to ensure it will meet your needs.
The other option that you have is there are fingerprint scanners that do what is known as match on device. These scanners have embedded matching algorithms and databases that do all the work for you. You get all the licenses you need when you buy the fingerprint sensor. These are really useful in embedded applications.
How do you handle a bug in a specific SDK version in a released application? Say for example I've reported and received notification that a bug is known in a specific version of an SDK. Say the SDK engineers fix the problem in the next release. Do I then need to check if the user is running the buggy release and display an error message that they can't use a specific feature with a bug in it because it will crash their hardware? Is there a more graceful way? Do you display an alert and tell them to upgrade to the latest SDK? Do you completely remove the feature? Advice would be appreciated.
This is phrased to be agnostic as possible, but I am asking for the purposes of iPhone application development at this time. General answers for other platforms would be nice as well.
It depends on the nature of the bug and on the nature of the platform. With the iPhone, for example, you cannot just tell the user to upgrade his or her phone. If your goal is to support iPhone version X.Y, then you will need to support the corresponding SDK; whereas, targeting browser X version Y.Z or Java version X.Y, it may sometimes be acceptable to tell users to upgrade.* Giving the impression that your application can do something only to give an error message saying that it cannot support it for that version of the platform does not make for a good user experience. If possible, try to work around the deficiency in the platform (by possibly reimplementing code that supposedly works in the SDK) and provide the feature to the user. If that isn't possible, then disable it when running on the deficient version of the platform, but be sure to remove all traces of that feature from the application (so that users don't click on a button only for it to tell them that the button is completely useless). I should add that conditionally enabling/disabling features is only sensible in the case where the feature is not essential to application; if a feature is a core aspect of the application, then you'd better find a workaround or raise the minimum requirements as it would not be appropriate to ship a deficient application to your users.
*An example where telling users to upgrade is not reasonable would be business applications, since business sys admins tend to be unusually lazy and users have no power to upgrade by themselves.
I've seen it happen reasonably often: I write an application in Delphi and when I compile it, the virus-scanner tells me that I've created a virus and then immediately deletes the executable again. It's annoying but reasonable easy to fix by doing a full rebuild, deleting the *.dcu files first and sometimes by simply waiting.
It happens with Delphi 6, 7, 2005 and 2007, as far as I know. And Symantec, Kaspersky, McAfee and NOD32 have all been guilty of reporting these false positives. I know it's because Delphi adds timestamps to its DCU files and these timestamps end up in the final executable and apparently appear to be part of some random virus signature.
I don't want to disable the virus-scanner, not even for a single folder or file. And I'm not really for a solution, but am wondering about the following:
Do these false positives also occur with other compilers?
Does it also happen with .NET executables?
Do others also notice similar problems with Delphi?
Do these false positives also occur
with other compilers?
Yes, this is has been a common problem in the past for AutoIt as addressed in this forum post "Are my AutoIt EXEs really infected?". In most cases including AutoIt it stems from poor heuristic practices. Since AutoIt uses the free and open UPX compressor, it is often mistaken for malicious code that also uses UPX.
The best (and possibly only) thing you can do is report these mistakes, so they can refine their heuristics or at least white list your app.
Below is a list of contact information for some popular anti-virus companies. They all claim to appreciate submissions as it helps them make their product better.
AntiVir - Contact
A2 (A-Squared) - Contact (email address)
Avast! - Contact
AVG - Contact
BitDefender - Contact
BullGuard - Contact
CA Anti-Virus - Contact
ClamAV - Contact
ClamWin - Contact
Comodo - Contact
ESET's Nod32 - Contact
eSafe - Contact (login required)
Fortinet - Contact
F-PROT - Contact
F-Secure - Contact
G-Data - Contact
Kaspersky - Contact
McAfee - Contact (email address)
Norman - Contact (email address)
Panda Anti-Virus - Contact
Sophos - Contact
Symantec (Norton) - Contact
Vipre - Contact
Windows Live OneCare - Contact
ZoneLabs - Contact
Turns out there is a great list of AV software on wikipedia, called 'List of antivirus software'. It is more complete than my list above.
A member of the Autoit Forums made a great script to e-mail a false positive to a huge list of AV vendors to automate this process a bit.
Sounds more like a heuristic screw-up to me. Do you have heuristics turned on (some scanners may refer to it as "virus-like code")? The chances that time stamps would equate to "a portion of some virus signature" seems too small to be happening all the time.
When I used to run a virus scanner, I never saw this problem with D6 or D7.
There is indeed Delphi virus in the wild, see http://www.sophos.com/blogs/sophoslabs/?p=6117
Yes, my team has experienced this maybe half a dozen times in 2-3 years with Sophos in a corporate environment. So, very rarely, but it does happen.
Our IT cretin started off demanding I review all the 1.5M lines of code in our app to "make it go away", but he didn't get too far pursuing that line...
To be fair, he was initially concerned that our clients might also receive such a warning, but we've only ever seen it triggered when building an exe from the IDE on a developer's PC, never on a release build exe on a test box or elsewhere.
Personally, it happens so rarely we don't worry about it.
I've had it happen to me with deployed code. The next update to the scanner solved the problem. Some cretin wrote a virus using the same compiler and the signature was part of the runtime library, not actually in the hostile code.
This is not that uncommon when using non-standard compilers or when doing fancy low-level stuff: I remember creating false positives when I dabbled in OS-development: AntiVir didn't like some of my flat binaries.
Recently, there's been a post about such a problem at the tinyCC mailing list regading AVG.
I've never seen this, having done lots of C++ and .NET development with Visual Studio (from version 1.5 to 2010).
I've only seen this happen with assemblers. For example, MASM32 actually warns people that it might trigger virus scanners since the EXEs are so small (and/or some viruses are written in assembly). My McAfee scanner flagged some of the example programs as viruses.
This should only happen for virus scanners that have a "looks suspicious" analysis mode.
In some apps, if I use RtlVclOptimize.pas, the Avira antivirus tell that I have created a virus.
plus to what others'v said, modern anti-virus programs rise virus-alert if your programs uses some "suspicious" APIs too ( like URLdownloadFile or other API hooking related ones).
if you google "delphi RAT FUD API undetectable" you'll find many interesting topics .
Some antivirus programs even flag a batch file as a virus and can't be convinced that it isn't. Quite annoying, if that file is part of a third party library and the virus warning is triggered every time TortoiseSVN checks it out. I ended up disabling the virus scanner, deleting the file and doing a commit. (Without disabling the scanner, I could not even do that :-( )
If you have problems with false positives, there is VirusTotal online service that can help you check your file against number of antivirus engines.
It's free service and currently it can run antivirus check with almost 40 antivirus engines.
A couple of years back, everytime we updated the GNU Linker from mingw sources and started distributing it with our compiler, we got some reports that virusscanners classified ld.exe as virus. (.exes writing .exes ...)
I would not call it a "false positive", because, strictly speaking, it is not false and the antivirus software is not "guilty" of anything in any way.
I am 99% sure, that this is the heuristic analysis acting up (I bet it detects your executable as something along the lines of win32.virus.generic - note the generic, this is a sign, that this is not in its signature db, but rather was detected by the heuristics) and, with being heuristic and all, it does not give you any kind of guarantee, that whatever it finds is malicious, it just kind of makes it known to you, that the executable is suspicious from its point of view.
The easiest solution to this would be just adding an exception for your file by name (it is always the same name, correct?). If you are uncomfortable with this, you should, probably, make your antivirus software prompt you before taking action so you can make it skip your file manually.
In general, I've found coding in windows with antivirus software somewhat irritating (don't do it much nowadays, but still), especially if the said software is in "paranoid mode". Irritating as it is, though, it is unavoidable (IMO).
I remember another weird one:
A file was being flagged as suspect. The only thing is the file was an .OBJ! An .EXE that contained the code the .OBJ contained wasn't considered a problem.
It happened to me too. Hooking keyboard will trigger almost any heuristic scanning AV software to report a key logger. There are probably many other system calls which will trigger it too.
Solution - try to redesign your code or contact the AV manufacturer to include your software into exception list.
VS Platform toolset 2010 renders my simple program to be detected as virus.
Changing the toolset to VS 2013 solves it.
It just creates a HttpWebRequest and writes the result to a file.
Every indication I have, based on my experience in embedded computing is that doing something like this would require expensive equipment to get access to the platform (ICE debuggers, JTAG probes, I2C programmers, etc, etc), but I've always wondered if some ambitious hacker out there has found a way to load native code on a Blackberry device. Anyone?
Edit: I'm aware of the published SDK and it's attendant restrictions. I'm curious if anyone has attempted to get around them, and if so, how far they got.
I've seen this question pop up in a number of different forums over time. The original Blackberries were programmable in C++ but I think that RIM ran up against the problems of trying to implement a secure platform in the C/C++ compile to native paradigm.
The devices do have JTAG ports, but unless one could get hands on the RIM code as a place to start the problem is enormous.
I also have to wonder how useful a Blackberry with a replacement FOSS operating system would be, since it would not likely have the protocols to connect to BES or BIS, send PIN's etc. If one was simply looking for a the power of the hand held computing platform I suspect there are many more likely candidates available.
No, C++ is no longer a supported RIM development tool, as they phased it out a number of years ago. Client applications can be developed in Java (or one of a few 5GL frameworks), and web + sever-side apps can be developed using standard tools.
For those looking for updated information, the new Playbook os, also known as QNX, also known as Blackberry 10 (or it will be when the phones running it come out) is in fact c/c++ based, also using QML and a C++ add on called Cascades.
Unfortunately the official SDK website only seems to mention Java. According to wikipedia, different versions of the BlackBerry use different processors. Combined with the fact that RIM uses a proprietary operating system for the devices, it becomes pretty difficult to develop native code without official tools. There is also a partial API-level security restriction which would further prohibit advanced tinkering.
Just randomly searching for an answer to this and came across http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Native-C-C-SDK/td-p/778009 which mentions that BB intend to release a C/C++ SDK soon, more details will be provided at the 2011 Game Developer Conference.