I cross-compiled a simple software from linux to windows through Fyne.
The software is pretty easy and straightforward, it just creates QR codes from an input given by the user, nothing special.
It works flawlessly but Windows Defender wakes up and alerts me there's a trojan, and it eventually deletes the .exe.
For more context, I didn't sign the software while compiling it. But I don't really need to distribute it, it's just a utility I'm going to use privately.
Any of you guys has experienced this issue before? Could be related to the cross-compiling procedure? Or maybe a sign is mandatory? Can depend by the QR code library I'm using, since it's the unique non-standard library I included?
There have been many reports of Go applications triggering windows virus detection, this is a problem with more than just your cross-compiled app.
As we live in a “default virus” world the defender rules need to understand Go apps, which has not yet happened.
In the meantime the only way to resolve this is to sign your apps I think.
Related
I am currently testing the GTK Application that I built on windows using the MSYS2 64bit shell.
For the program to be able to run outside of the shell, I packed all the required DLLs with it as well as the following:
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders\\*
FOLDER\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache
FOLDER\share\glib-2.0\schemas\gschemas.compiled
FOLDER\share\icons\Adwaita\\*
FOLDER\share\icons\hicolor\\*
The good news is: It works :) And it also works flawlessly on another PC that doesnt have GTK/Msys2/whatever installed.
The bad news is: On yet another PC (I have tested it on 2 other Systems other than my developing System so far, one one of them it works flawlessly), the program itself works, but the GUI is not rendered sharply (texts are blurry).
Do you guys have any idea on what could be the reason for that? I'm guessing it could be one of the following:
The affected system could have some general display problems that have nothing to do with my app.
The gschemas.compiled file does not suit the affected system. In that case I would probably have to create that file dynamically, but I have no idea how to do this.
I am missing some file from GTK or Glib that would solve the problem.
I am thankful for any help :) Compiling/Deploying a GTK App for Windows has proven to be a pain in the ***, but since (almost) everything works now, I feel like its not much that I am missing unless I have overseen something critical.
Regards,
tagelicht
Given the way you created your package, my bet is that you are missing some components, making the drawing code use some fallback routines, hence the "sharp" drawing.
Try to run the application in command line on the machine where your have the problem, to see if there are some unusual warnings you don't have when running it on your machine.
See also my answer on how to distribute a GTK+ application on Windows.
I am developing some freeware applications. Mostly they are written in Java to make them run on multiple systems. Meanwhile I have some thousand users and so it makes a lot of fun.
To make the Java apps easier to run under Windows, I also create executable wrappers using launch4j and installer applications using inno setup.
Now I have problem, because of Windows 8. In former Windows versions the OS just showed up a message by trying to start such an executable which was saying that the exe file comes from an "unknown" vendor. In Windows 8 they made it even harder. There is something like "Windows protected you from this dangerous application!".
So I am highly interested in signing my apps. But I am not willing to pay anything for this as I offer my software for free. Using Google I found the "CAcert" project that allows people to create free certificates. But I haven't found detailed information about the following questions:
can I create certificates to sign executables?
can I create certificates using my company name?
Is there anyone familiar with CAcert?
Or has anyone another hint to solve my problem?
thanks a lot...
Well, you can use use a CAcert certificate to sign your code, but it won't help you. That's because the OS doesn't install the CAcert root certificate.
If you want to stop your users seeing these messages you'll need to obtain a commercial certificate.
For a university course I have to write a http server which is supposed to run on both Linux and Windows.
I have got a humble Linux machine which I don't think can handle any kind of heavy virtual environment, neither I'm willing to go through the hassle of installing it.
This is the first project of mine complex enough (I estimate ~1.5 months to develop) to require an environment sufficiently comfortable to alternate rapidly between short coding and testing sessions (the latter on both platforms, of course).
So, I was wondering what could be the best set up for this situation. I think testing it on Wine would be ok (it is not a real-world thing, after all), and I installed MinGW for the Windows-targeting part.
Basically, a simple well-written makefile could solve my problem... It should build both the Linux and Windows binaries and place them in the respective folders (the Windows one in the Wine sub-tree) and I'm all done! But I feel very inexperienced in this thing and I really don't know where to start. Maybe the make manual, ahah!:)
Thoughts, suggestions, anything I didn't think/know!
Thank you!
(PS. I'm planning to use emacs as editor, or maybe learn vim. Unless eclipse provide some kind of skynet-like plugin that entirely solve this problem...:)
You're on the right track. It's not that complicated, really, thanks to MinGW. You basically need two things:
The code has to be portable across the OSes. MinGW has some POSIX support, but you'll probably need to either use Cygwin in order to be able to use the POSIX interface or have your own compatibility layer for interfacing with the OS. I'd probably go for Cygwin as then you can code only against POSIX and won't have to test and debug your compatibility layer. Also, make sure you won't use any external libraries that are OS specific. Non-portable code often results in a compile error, but make sure you test the application thoroughly anyway.
The toolchains for targeting Linux and Windows. You already have them, you just need to use them correctly. Normally you'd use a variable like $(CROSS_COMPILE) as a prefix when calling the toolchain during cross compilation. So when compiling for Linux, you call gcc, ld, etc. (having the CROSS_COMPILE variable empty), and when compiling for Windows you call e.g. i486-mingw32-gcc, i486-mingw32-ld etc., i.e. CROSS_COMPILE=i486-mingw32-. Or just just define CC, LD etc. depending on the target.
I wrote a small game on Linux and made it run on Windows as well. If you browse the code, you can see the code has next to no #ifdef jungle (basically just some extra debugging features enabled for Linux), and the Makefile is simple as well, with no complicated handling for cross-compilation, just the possibility to override CC etc. like it should be. As lots of important open source software is written this way (especially software that's used by the desktop and embedded devices), you should also be able to find lots of other examples on how to set up the build environment correctly.
As for testing the application on Windows, I think the best option is if you can find a real Windows machine somehow. If you do everything correctly, it should run the same as on Linux and you won't need to continuously test your application on both OSes. If testing on a Windows machine is not possible, a VM would be the next best choice, though it would probably be more difficult to set it up. Wine is a good backup plan, but I don't think you can be sure your application works well on Windows if you only tested it on Wine.
Someone I used to work for emailed me out of the blue and said they want me to update a VB3 (!!!) program I wrote for them because customers are reporting having problems running it under Windows 7. They have lost the source code (natch). Is there a decompiler for VB3?
For decompiling VB "DoDi VB3 decompiler" is the best tool available. The results are pretty good.
However the original is anno 1997. VB3 is 16 bit code only + still some bugs + no source code. These makes that tool hard to get running on windows beyond Windows XP and limits it's use.
DoDi's VBDIS3 it self is also written in VB3 - so about 10 years later just for fun I cracked it to make the decompiler to decompile it self.
... and ported it to VB6!
So now you've the source code !!! :D
... and it's 32 Bit code + some bugfixes and improvements to the original:
DoDi's Visual Basic 3 Decompiler [Reloaded]:
http://vbdis4.angelfire.com
Screenshoot:
in case that website get lost Google for
'VBDIS3.67e_Reloaded_Rev3_DoDi_s_VB3Decompiler.7z'
or try the internet archive
http://web.archive.org/web/20090301170633/http://vbdis4.angelfire.com
I remember looking for Visual Basic decompilers/disassemblers a long time ago to no avail. There may be things out there now though. The most I could come up with was PE Explorer: http://www.heaventools.com/overview.htm
Have you suggested running your application under Windows Compatibility mode: http://www.sevenforums.com/tutorials/316-compatibility-mode.html
Edit: Further Googling: http://www.w7forums.com/visual-basic-3-0-compatible-64-bit-version-t5146.html
I maintain legacy 16-bit VB3 software
that is compatible with Windows 7 and
have done a lot of research in this
area.
16-bit applications will not natively
run in Windows 7 64-bit full stop.
This is because when a 64-bit capable
CPU is started in 64-bit mode, it
cannot change into 'real mode' (the
mode used by 16-bit applications)
without a hard reset. If a processor
is in 32-bit mode, it can swap between
real mode and protected mode at will.
The only workaround here is a virtual
machine- Windows 7 comes with a free
version of Windows XP which is usable
inside a custom version of Microsoft
Virtual PC. Google for "Windows 7
Virtual XP Mode". Once your copy of
Windows 7 has been validated as
authentic, it will allow you to
download Virtual PC and the XP Image.
It's definitely not a pretty solution,
but the only option for my customers
who have gone ahead and bought a
64-bit OS without checking to see if
their installed software is 64-bit
compatible.
Unlike the later versions which used native code and are generally not reliably decompilable, VB3 (and, I think, VB4) could be usually decompiled to almost original code. The keywords you need to search for are "DoDi VB3 decompiler" or "vb3dis". Here's a page that seems to have a copy.
Really? VB3, if it runs fine in XP, should be okay in the Windows compatibility box.
What I would do is to say that you couldn't find anything suitable (which is almost certainly true) but that you may be able to fix their problem for a moderate fee. Then, hopefully it's just a matter of setting a flag on the application (you may want to check this first to ensure it won't be too much work).
Money for Jam.
The other option is that you can offer to rewrite it for them in a more modern setting, using your vast knowledge of the application.
However, I'm surprised you don't have a copy lying around. I keep just about every piece of software I've ever written just in case (with permission for work-for-hire stuff of course), even down to the Fortran assignments I did at Uni back in the early 80s.
That's a good habit to get into, although I'm starting to wonder whether I should perhaps free up some space by ditching the Fortran :-)
There are a number of things you can do to help them without the source code. You could apply an external manifest if the application will only work when it is elevated. You could advise them to install the application somewhere other than Program Files (generally an awful idea, but might work in this case.) You could apply a compatibility setting or teach them how to install it into "XP mode" so it runs in an XP virtual machine.
Failing all of those, you could offer to rewrite it in VB.NET so they would get a more modern ui, Windows 7 features (not just capabilities) and would actually own the source code for their app. That might have value for them.
And yes, you should have kept the code. I have CDs burned from my old projects going back to the dawn of time (at some point I copied things from 3.5" backups to CDs while I still had some machines that could do both) and I have made more than one previous client happy by sending them the CD. It is a really cheap marketing investment, really.
It sounds like this is an application that is sold to customers, and is having trouble or doesn't work under Windows 7.
Consider advising the customer that the application should be:
modernized, thereby easing the ability to add features/maintained
otherwise run in XP Compatibility mode for their Windows 7 customers. Surely that number will only grow, and would become a support issue. Goto previous bullet.
Seriously though; your customer should realize that their software needs to be modernized. Hopefully you can persuade them of that long term goal; perhaps they already know that.
In a nutshell, I want to write my own device driver for windows, so that I can emulate a piece of hardware. I know very little about writing device drivers for windows, but I have a very firm understanding of the C and C++ languages, and I know enough x86(_64) assembly to get around.
I'm not really sure how one would go about even compiling a device driver, or what is required to create one. I'm certainly not against coding the entire thing in assembly if that needs to be done, but does it?
I'd like to do this using Windows tools obviously, I'm planning on trying to put it together using a windows GCC compiler, but I've got access to Visual Studio if that's needed. Can someone point me at resources that would be helpful, like reference manuals, tutorials, specs?
Oh: My target OS here is Windows 7, 64bit, which if I understand should be the same as Windows Vista 64bit, but correct my wrongness if it exists.
Thanks.
Everything you need to build your driver (including the compiler) comes from the WDK. Everything you need to know what to write comes from Walter Oney's books. Be prepared for a rough ride.