I have written a plugin for vanilla lua. I wish to protect this plugin, and I have heard of obfuscation. I tried XFuscator, but even after fixing line 5's logic, it doesnt work. Are there any newer, better ones floating out there?
Thanks!
If you are going to run your Lua script in the same machine you build it (I mean, same Lua version, same machine architecture), you could just compile it to bytecode using luac like this:
luac -s -o example.out example.lua
And distribute the .out file, that doesn't contain the Lua source code.
Note that Lua bytecode is platform specific (endianness, word size), and it could change in future Lua versions (in fact it already did in the past). For that reason, if you compile it, let's say, in a Intel x86-64 with Lua 5.3, you should run your generated .out only in this kind of machines or compatible ones.
Related
I have begun to use GTK(2), and I find that the workings of the library to be very good, but the documentation sucks.
I want to upgrade to GTK3, but it seems I need to install something called packman. That is a difficult philosophical step for me. Why can't I simply download a zip file(s) somewhere?
The documentation uses a lot of words without saying much, and the downloads want you to download stuff OTHER then gtk in order to get gtk. Why don't they simply have a GTK package and let me decide if I need all the other stuff.
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
Anyway, that is mostly a rant, what I'd really like is a suggestion to an alternative to GTK+.
Here are some of my requirements...
#1, It must NOT be an interpreter. Using Code::Blocks and C, I get an exe file and I'd like to continue that way.
#2 It must be programmable using C. I'd really like to stick wiith C::B, but I guess in a pinch I can use Eclipse (although that is another nightmare I won't get into here.)
#3 GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
Any suggestions woule be apreaciated.
Thanks, Mark.
You best bet is to give a look at https://en.wikipedia.org/wiki/List_of_widget_toolkits#High-level_widget_toolkits
If you wan to stick to C and not C++, then Qt is out.
The other that stands out is EFL. I've never used it myself, but it has good reputation and probably your best bet if you want to quit GTK+ and stick to C. However I don't know how easy it is to use it on Windows.
Now about GTK+:
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
There are people here that use GTK+ with Code::Blocks, so I don't get what kind of problem you're referring to.
Then your other problems:
The documentation uses a lot of words without saying much
Examples?
the downloads want you to download stuff OTHER then gtk in order to get gtk
What you don't get is that GTK+ is more that just the libgtk library. It has dependencies on a lot of other libraries, like glib, cairo, pango, etc. In the past there used to be a bundle or installer to have that installed on Windows, but people would mess up on setting the environment up based on their needs and give up. As the GTK+ manpower for the Windows platform is limited, the GTK+ team delegated the distribution of the GTK+ binaries to the MSYS2 project.
MSYS2 is a popular project that provides a lot of open source software already built for Windows, and solves the problem of building and installing dependencies by hand for the user. This step is made to make installation simpler, not harder. In a handful of commands you have GTK+ and all its dependencies installed for your platform, and can start coding your app. Another command and you have python and the python GTK+ bindings installed and can get started. Want to depend on another popular library? Chances are MSYS already provides it.
Windows has been known for decades to be bad on dependency management. If package management wasn't a a pain point on Windows, then stuff like chocolatey or conan wouldn't exist.
Your philosophical reluctance is merely that: philosophical. Sure GTK+ on Windows isn't perfect. With MSYS2 you will get packages built with gcc so the debug symbols are not compatible with the Visual Studio debugger and you will need to use gdb instead. But on your other question you say you use gcc and loathe Visual Studio, so this should not be a blocker to you.
GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
This is not possible for the moment as static compilation of GTK+ isn't supported. The redistribution of an app, however, isn't as easy as I'd like it to be. The best way on Windows to redistribute your app while using MSYS2 is to create a pacman package for your app, listing its dependencies, then call pacman to install your app on an empty directory and tell it to install all your dependencies there too. The result will be a directory that you can redistribute, with a self-contained installation of your app and all its dependencies, GTK+ included.
I have a little benchmark suite, which compares different approaches to writing and executing some simple toy Python code, mainly for the purpose of illustrating Cython.
One of the approaches I used to have, was to write the test function in pure C, compile it with a C compiler (getting distutils to find and invoke the compiler for me) then load the library into Python with ctypes, and execute the function.
This worked swimmingly until distutils started embedding the python version and the platform in the name of the file it generates.
In the past I could persuade distutils to compile a C source file called C.c into a library called C.so in the working directory: recent versions of distutils insist on mangling the output name into something of the form build/temp.linux-x86_64-3.6 or (depending on exactly what distutils features I use) some other variaton on that theme.
Is there any way to persuade current versions of distutils to simply call the output C.so in the current working directory? (Alternatively, is there some way to reliably and easily tell ctypes where the library produced by distutils resides?)
[Bonus: How can this idea be expressed portably across Linux, OS X and Windows?]
=================================================================
Edit: for completeness, here is how I used to do it successfully in the past:
pure_C_setup.py:
from distutils.core import setup, Extension
setup(name="ctypes-test",
ext_modules = [Extension("C", ["C.c"])])
With the above setup file, the command python pure_C_setup.py install --install-lib=. used to produce C.so in the working directory; today it produces build/lib.linux-x86_64-3.6/C.cpython-36m-x86_64-linux-gnu.so
Not platform, not even compiler independent, but you might be able to use Extension's extra_link_args to achieve what you want.
For VCPP 2015:
setup(name="ctypes-test",
ext_modules = [Extension("C", ["C.c"], extra_link_args="/OUT:C.pyd")])
I have a Perl script I wrote for Linux. Now I'd like run it on AIX and Solaris (each one separately). Will I have to compile them (I prefer not to provide my users the uncompiled script).
Do I necessarily need AIX or Solaris machines to compile them?
If you have written your script such that it isn't using any platform specific features or commands, it should be fully portable. Refer to perlport for some more detail. Within Unix you're generally OK, but AIX is a bit of an odd Unix.
But in terms of compiling? Perl doesn't usually "compile" in the conventional sense. If you are compiling it into a binary executable, then this will be platform specific - you can occasionally 'get away' with a binary from Solaris/x86 running on Linux/x86, but it's better to assume not.
So yes, you will need to "compile" it on your specific architecture.
I would suggest that you don't actually need to though - perl is a scripting language, and script are plain text. Let their local installations of perl deal with the 'compiling' bit, and stop worrying about it. You honestly don't gain very much trying to compile perl anyway - at best it's an crude and trivial form of obfuscation.
Have a look at perlcompile to get a better understanding of this process.
I am using cygwin64 installed in C:/cygwin64, with eclipse and GTK2.0. Although include <gtk/gtk.h> is in the source, and C:/cygwin64/usr/include/gtk-2.0 is in the include path (I added it), many things in a gtk2 simple example are still not recognized, such as GtkWidget, gpointer, and GTK_WINDOW_TOPLEVEL. I got the whole of GTK2 via cygwin setup. I was and am reluctant to download all of GTK2 separately and install it on top of cygwin, since wouldn't it result in multiple locations for the same thing? How may I resolve it? Would separate download and installation not result in redundancy, and possible alternate or even conflicting aliases?
A secondary question: I am confused about the general library requirements. Cygwin is a package which runs on Windows, but offers a Linux/unix-like interface. This argues that the libraries should be .a and .so. But since it is Windows, I also see a lot of .dll within C:\cygwin64. Normally, I would expect that only cygwin proper would contain .dll files and all other code would be Linux code. Yet that seems not to be the case. Often, I see both .dll and .so libraries with the same base name. Which is it, dll, or .so and .a, etc?
A tertiary question relating to the one above involves the main gtk2 library. The projected usage is not developing these programs, but just using GTK2 in applications. The documentation says to use glib, but there are many. Some are glib2.so, others glib2, or cygglib2.0.0.dll. Which of these is appropriate? or some other library? How do I set the exclipse LIBRARY path? (Since I unexpectedly encountered the problem with gtk.h, I am trying to anticipate and head off the corresponding problem with the library implementing gtk2.)
This is probably a multi-part question. Background: we have a native (c++) library that is part of our application and we have managed to use SWIG to generate a perl wrapper for this library. We'd now like to distribute this perl module as part of our application.
My first question - how should I distribute this module? Is there a standard way to package pre-built perl modules? I know there is ppm for the ActiveState distro, but I also need to distribute this for linux systems. I'm not even sure what files are required to distribute, but I'm guessing it's the pm and so files, at a minimum.
My next question - it looks like I might need to build my module project for each version of perl that I want to support. How do I know which perl versions I should build for? Are there any standard guidelines... or better yet, a way to build a package that will work with multiple versions of perl?
Sorry if my questions make no sense - I'm fairly new to the compiled module aspects of perl.
CLARIFICATION: the underlying compiled source is proprietary (closed source), so I can't just ship source code and the appropriate make artifacts for the package. Wish I could, but it's not going to happen in this case. Thus, I need a sane scheme for packaging prebuilt binary files for my module.
I look after DBD::Informix, one of the Perl Database Driver modules that works with the DBI (Perl Database Interface). The underlying libraries used to connect to IBM Informix Dynamic Server (IDS) are proprietary, but the DBD::Informix code itself is not. I distribute that code on CPAN, just the same as any other Perl module. People can download that source, and (provided that they have the Informix ClientSDK installed on their machine - and Perl and DBI and so on), they can build DBD::Informix to work with their installed Perl.
I would strongly counsel that you arrange that your Perl interface code be made available in source form, even though the library that it interfaces to is proprietary. This allows people to install the code with any version of Perl they have - without requiring you to deal with inconsistencies.
If you still want to provide binary support, you are going to have to work out which platforms you want to support, and build the module with the standard version of Perl on each such platform. This gets messy. You need access to an instance of each machine. Granted, virtual machines make this easier, but it is still fiddly and the number of platforms and versions only grows. But you still need to support people who don't use the standard version of Perl on their machine - that's why the Perl wrapper interface needs to be provided in source form.
DISCLAIMER: I have next to no experience creating binary packages that can easily be installed. Therefore, I am making this post CW to make it easier for others to add their advice.
You should make the distribution available in source form so it can be compiled on each system tailored according to the specifics of that system. I really like Module::Build for that purpose.
For ActiveState users on Windows, you probably want to have four or six PPMs based on whether you want to support 5.6. Package both 32-bit and 64-bit versions for each of 5.6, 5.8 and 5.10. Use the version of mingw you can install using ppm to compile the modules to preserve binary compatibility.
Another option is to use PAR::Packer and distribute your application in a PAR archive. In that context, PAR::WebStart might be useful although I have not tried it. I have had success with PAR archives in the past, though.