I'm writing a program that download a file(dll) from my server and use this file.
But, when the download is complete, my antivirus (Kaspersky) detect my file with Constructor.Win32.Downldr.xr. How can I solve this?
However, I put my 2 files in www.virustotal.com and both have no virus.
Note: The two files (the program that makes the download and the file, that is a dll) are made in Delphi 7.
You can't expect to bypass the anti-virus software so that leaves two options:
Persuade the AV vendors that your DLL is clean and get them to update their signatures.
Change your DLL sufficiently so that it does not fall foul of the scanners. That's going to require trial and error I guess.
In a previous question you asked how to download a DLL file to memory and then load it from memory rather than a file. I expect most good anti-virus software would regard any software that does that as being malware.
If I were you I would download to a temporary file and use the officially supported LoadLibrary to load the code. The AV software may be more lenient to that. If you are not prepared to do that then your software probably is malware in my eyes, even if you don't mean harm. Even if you do that, downloading and executing DLLs from the internet without the user's explicit consent is verging on malware in anyone's eyes.
Let's put it another way. I would never let this program of yours run on my machine and I would be pleased when my AV software flagged it.
You may also try to use HTTPS or any secure connection when downloading the file. Some antiviruses can't look to cryptographed connections.
Related
I would love to be able to update my NodeMCU ESP8266-01 OTA, since they're located in awkward spots. I'm by no means an expert regarding the ESP or NodeMCU, but I haven't been able to find anything recent about OTA updates. I found some discussions about it going back to 2015, but it never seems to have been implemented.
I use my ESP with NodeMCU to control a PWM dimmer. I upload a precompiled version of NodeMCU with the NodeMCU Firmware FLasher, and then use ESPlorer to upload a custom lua file called 'init.lua'. I'm not even sure if this is the proper way to do stuff, but it works.
So the main question: Has OTA updating been implemented, or is it possible in some way?
Just to clarify, I don't think I want to update the firmware. As I understand it, firmware is what you build yourself, or on a website like https://nodemcu-build.com. I want to update the lua files that run on the ESP, that you normally upload through a program like ESPlorer.
I found some discussions about it going back to 2015, but it never seems to have been implemented.
Indeed, firmware OTA is not available yet. However, as you probably know, the need for firmware OTA is much lower with the NodeMCU firmware than e.g. with the Arduino platform. I'd argue that you're much less likely in need to replace/upgrade/extend the firmware with its built-in modules than the application code that runs on top of it.
Fortunately, it's quite simple to replace one or several Lua scripts (compiled or uncompiled) on the device and reboot it. All the web and cloud IDEs listed at https://frightanic.com/iot/tools-ides-nodemcu/ offer this. There's even a pending PR that'll bring FTP support to NodeMCU.
For a complete Lua provisioning system take a look at what #TerryE provided at https://github.com/nodemcu/nodemcu-firmware/tree/master/lua_examples/luaOTA
I've attempted to use the two Web IDEs listed in the link provided in Marcel Stör's answer, but I honestly failed to understand how to use either IDE. they also seemed like they weren't exactly what I was looking for, and required a server to connect to, or an extra program, which I wanted to avoid.
Edit: Apparently, I did end up using one of the two Web IDEs in the list. Since it's been a while since I did all this, it's a bit fuzzy in my head.
I eventually stumbled upon this GitHub page, which seemed to provide exactly what I was looking for: The ability to access the Lua files on the ESP through a webbrowser. I have personally changed the ide.lua file around completely, since I needed to call functions from it in the init.lua script. However, I think you can just upload the ide.lua script to the ESP, and add a line containing dofile("ide.lua") to your init.lua file.
If anyone is interested in my changes to, or my implementation of the ide.lua script, you can take a look at my repo Timmiej93 / QuinLED / Program code.
In fact there's a class for that to implement OTA i the NodeMCU its called the ESPhttpUpdate you can refer to ESPhttpUpdate for further details.
We have an old VB6 project that uses ActiveX controls, some of which we build and others we get from third-party vendors.
Currently, we use a .csproj project which does the following,
Execute regsvr32 to register the OCXs
Execute vb6 to build the VB6 project
Execute regsvr32 to unregister the OCXs
This registering/unregistering is ugly and is a bit of a pain for local developer builds with UAC enabled. Is it at all possible to build a VB6 project without having to register any controls?
I apologize if this has already been asked before. The only similar questions I was able to find were about how to build VB6 projects, and answers to these mention the same solution of register, build, unregister.
It sounds like these people are merely working on clients of these OCXs rather than modifying and recompiling the OCXs themselves.
If so, you should be administering the installation of these libraries just as you administer the VB6 development system itself. This means each workstation needs to have the control suites you are using installed once (well, and maintained when new releases are placed into use). Installers for developer libraries deploy things like .DEP files as well as design-time license key registry entries, so using regsvr32 shouldn't be considered a viable strategy anyway.
If you set the developer workstations up properly and maintain them there isn't any reason to be registering and unregistering such things.
It means the original developers probably did not set the "binary compatibility" correctly. Which means the VB6 dll's get a "new com guid" every time they are built.
Which means your original VB6 developers were probably a bunch of hacks.
You can read the section here on Binary Compatibility.
http://support.microsoft.com/kb/161137
Get in a time machine and go back and punch the person in the face who said "We don't need
to work out the binary compatibility issues now, we'll just unregister and re-register the components... Easy Peezey!"................
If I'm wrong, please let me know. But every time I've seen "unregister the com" and "re-register the com".........it goes back to that brainiac decision.
Here is a longer discussion on it:
http://www.techrepublic.com/article/demystifying-version-compatibility-settings-in-visual-basic/5030274
EDIT:
If the ocx's are not changing........then you should only have to register them once on the build machine once.
The direct answer is no, it is not possible to compile a VB6 project with OCX dependencies without those dependencies being registered.
Furthermore, the act of compilation itself involves VB6 attempting to register what it has just built (unless you are compiling to an EXE). This generally requires the VB6 IDE and/or its compiler to run with "admin" permissions. Therefore the permissions are a hard to avoid issue regardless.
I believe these issues can be obfuscated by the fact that VB6 itself (the IDE and/or the runtime) will sometimes try to automatically register certain things for you, but will keep silent when it does so.
You should probably create a different process to setup a development PC from the build process you use from deployment. This may "feel" wrong especially if you have experience with other programming environments, but I would stress that VB6 can be very painful & problematic to work with and so pragmatism is generally in order.
On the development PCs: Setup all the unchanging dependencies once (and document them) and then leave them alone (as noted in another answer.) When weird dependency problems occur, verify the PC is setup correctly before doing anything else.
If you have all the sources to your dependencies, then I would consider if you can actually run them all in a VB6 project group (VBG) and not compile them at all. (A VBG is akin to a .NET solution though far less powerful.) I do this often and it cuts out a lot of wasted time. Developers don't necessarily need code compiled to EXE / DLL / OCX - they often just need to be able to run it in the IDE.
On the build PC: If you can always start with a clean environment, like in a virtual machine, then I think its actually a good idea to register everything from scratch in an automated fashion as this helps to verify nothing is missing or mismatched. Re-using the same build environment without doing this can mask problems when some dependency has changed in source control but still exists on the build machine. On a VM generally permissions aren't a limiting factor.
Notes:
If you are building an EXE, VB6 does not require any elevated permissions, as far as I can recall.
Running code in the VB6 IDE does not either.
[Caveat 1]:
It may technically be possible to create a side-by-side application manifest file for VB6.exe itself and include in that manifest whatever dependencies you need, thereby avoiding having to register them.
But this would fall well outside of the normal ways to use VB6 tools - its a hack - and possibly is not worth the potentially large effort. I don't think I've ever seen a working example and so I don't recommend this as a practical solution, but mention it for completeness.
Maybe in some locked-down corporate IT scenario this could pay off... maybe. In that scenario doing dev work in a VM might be a better option though.
Users have been reporting problems/crashes/bugs that I can't reproduce on my machine. I'm finding these problems difficult to fix.
I've started using EurekaLog (fantastic!) and SmartInspect. Both these tools have helped greatly but I'm still finding it difficult to catch some problems.
I've just purchased Debugging by David Agans (and waiting for it to arrive).
Are there any other tools or techniques specific to Delphi that will help with catching these hard to find remote problems? The kinds of problems I'm finding difficult to track down are those that don't raise exceptions or have a clear cause. EurekaLog catches exceptions and SmartInspect is pretty good once I have a theory to check. But in some cases it is a seemingly random crash and there are several thousand lines of code that may may be at fault. How to narrow down to the root cause?
MadExcept is what I use, and it is fabulous. I have also used EurekaLog and find the functionality almost exactly identical, except that I have more experience and time using MadExcept. it's free for non-commercial use, and reasonably priced for commercial use.
Update: MadExcept 4 is now out and even supports 64 bit Delphi XE2 apps, and has memory-leak checking too.
When nothing blows up, I rely on heavy use of trace logging. I have a TraceMessage(integer,string) function which I call throughout all my apps, and when someone has problems I get them to click a menu item that turns up the debug trace level to the most verbose level; it gives me a complete history of everything my application did, and this has helped me even more than madExcept, to solve problems at customer sites. Customers get a crash, and that crash report sent by madexcept contains a log file (created by my app) that is attached automatically. I believe you can do this equally well with madExcept and EurekaLog. If you need a logging system you could download Log4D, or you could write your own, it's pretty simple.
For always-free, try JclDebug, which requires more work to set up, but which has worked fabulously for me, also.
For help with heap problems, learn more about fastMM (full version) debug options.
And you shouldn't forget that Delphi itself supports Remote debugging, if you can reproduce a crash on machines in your office that don't have delphi installed, use remote debug across the office network instead of installing a complete RAD Studio installation on that other machine at your work. You could also use remote debug to connect to a client PC computer across the internet, but I have not tried remote debug across the internet yet, so I can't say whether it works great over the internet or not. I do know that since remote debug doesn't support automatic deploy of the EXE file you built (you have to do that part yourself), remote debug over internet, to a client PC is more work.
You might also find lots of your problems by fixing all your hints and warnings, and then going through with CodeHealer or Pascal Analyzer (PAL) from Peganza. These static analysis tools can help you find real code problems.
If performance and memory usage are your problems, get the full version of AQTime, and use it to profile and watch your system operate. It will help you fix your memory leaks, and understand your app's runtime behaviour and memory usage, not just leaks but bottlenecks for memory and CPU usage. Some of those bottlenecks can also be the source of some odd problems. I have even used AQTime to help me find deadlocks, since it can generate traces of execution, that can help me figure out what code is running, and locate deadlocks. Update: AQTime is not installable on machines other than your main dev machine, without violating the newly modified license terms for AQTime. These terms were never this restrictive in the good old days.
If you gave more exact idea of what your problems are, I'm sure other people could give you some more ideas that are specific, but all of the above are general techniques that have served me well.
One of the best way is to use the Remote Debugger that comes with Delphi, so you can debug directly the application running on the remote machine. THe remote debugger is somewhat buggy in some Delphi releases, and requires to follow the instructions carefully to make it working, but when needed it's a tool to consider. Also check if there are updates available for your version, they could come in a separate installer for deployment on "remote" systems. Otherwise first install the remote debugger, than check if the files installed has newer versions in your local installation, and the copy tehm on the remote machine.
CodeSite has helped me a lot in these situations. Since XE it is bundled with Delphi.
Logging is the key, in this matter.
Take a look at our TSynLog class available in our Open Source SynCommons library.
It does have the JCL Debug / MadExcept features, with some additional (like customer-side profiling, and logging):
logging with a set of levels;
fast, low execution overhead;
can load .map file symbols to be used in logging;
compression of .map into binary .mab (900 KB -> 70 KB);
inclusion of the .map/.mab into the .exe;
reading of an external .map to add unit names and line numbers to a log file without .map available information at execution;
exception logging (Delphi or low-level exceptions) with unit names and line numbers;
optional stack trace with units and line numbers;
methods or procedure recursive tracing, with Enter and auto-Leave using interfaces;
high resolution time stamps, for customer-side profiling of the application execution;
set / enumerates / TList / TPersistent / TObjectList / TContainer / dynamic array JSON serialization;
per-thread or global logging;
multiple log files on the same process;
integrated log archival (in zip or any other format);
Open Source, works from Delphi 5 up to XE.
Resource files (.RES) accept any kind of binary files but if it is an exe file how can I run it?
You would have to extract it as a file to disk and execute it.
Although you don't have to extract it to disk, as Cosmin Prund says in a comment, if you don't it requires a lot of hard work.
http://sites.google.com/site/delphibasics/home/delphibasicssnippets/memoryexecutionunit-winxpwinvistawin7
Take a look at this memory execution unit.It allows you to execute an exe from memory without dumping it on disk.
Yes it is possible. There is a Delphi library to do this somewhere on the web, but I cannot for the life of me remember what it's called. It allows you to execute a normal exe file no-matter where it is in memory. So you can load it into a stream, or just embed it in a resource.
I realize that my reply is a bit depressing since i dont remember the name of the library, but at least you now know that it can be done. If you google around for "execute PE exe from memory" and "Delphi" then I'm sure you will find it.
You might want to take a look at Orean's XBundler: http://www.oreans.com/xbundler.php
I use their licensing product (WinLicense) and have been very happy with the product, their support, responsiveness and updates.
In fact, I'm about to buy XBundler so I can ship a dll securely embedded in my exe.
Tom
I wanted to try out the TCC and got the Win32 Binary zip file from the website.
upon decompressing it I tried to compile the "hello_win.c" source from the example directory. As soon as the compiler tried to write to the disk McAfee Popped up a dialog box and identified a Trojan named "Generic.dx." Has anyone else experience this? Dropping a virus into a compiler would be a sneaky, but brilliant, delivery mechanizism. I just want to know if this is a legit threat.
Have you tried any other virus scanners? McAfee is notorious for false positives. What does the TCC website say about it? Have you googled it? I'd rather doubt it is actually a virus.
Upload your *.exe file to http://www.virustotal.com/ to see which Anti-Virus scanners react to the file. I have had similar issues with Delphi. (See discussion at Wikipedia.)
By definition, compilers modify executable files. It is quite possible that your antivirus is flagging this behaviour as a "generic" virus. If you download your executables from a reputable source, and if they pass virus detections inside tcc.exe itself, most likely this is a false warning.