Slashdot Mirror

This also means serious damage to RIA aproach too. Without QT, it was very difficult to create cross-platform apps (running on OSX, Linux and Windows).

Java was an option, but too few people used it for small apps like shareware utilities.

RIA was an option, but their are immature and do not allow to implement a lot of things.

Gtk was another ugly option.

Also running web server locally (e.g. with web server for CD and USB drives ) was elegant option for some cases when UI is rendered by web browser and backend is implemented using server-side programming language like php or python running locally.

Now it seems a lot of shareware authors will start using QT even for developing Windows-only apps. This means a lot of new apps that are stable and cheaper to develop will enter the market soon. Hopefully most of those apps will probably be ported to OSX (and even Linux) by their authors afterwards.

I hope they are running Wiki directly from CDs. There are some web servers for running sites from CDs, some of them even allow to start web server and php, perl, python, java server-side scripts directly from the same cd on Windows, Linux and Mac OS X.

Fortunately, tools to hide source code for trully interpreted (dynamic) languages also exist (here is a sample catalogue of JavaScript, Perl and VBScript obfuscators), though sometimes they require adaptation of source code.

If your code uses C/C++, then use tool similar to Stunnix C/C++ Obfuscator; for Perl, JavaScript and VBScript/ASP obfuscators also exist from that company and several others.

A viable option is assigning a dedicated coder from your team to that customer ("lease" him to them) and fork your code for them - this way their developers won't spend monthes studying your code before being able to produce anything useful.

If your code uses C/C++, then use tool similar to Stunnix C/C++ Obfuscator; for Perl, JavaScript and VBScript/ASP obfuscators also exist from that company and several others.

A viable option is assigning a dedicated coder from your team to that customer ("lease" him to them) and fork your code for them - this way their developers won't spend monthes studying your code before being able to produce anything useful.

1. perlcc to compiled code doesn't work for compiling to C for most of code (and generates 5-10Mb of C code that compiles for 10 minutes by gcc) and result doesn't work almost all of the time. Output of 'perlcc -B' can be reversed using B::Deparse..

2. ActiveState PerlApp just extracts all your project's files to a temporary directory during execution of your "compiled" code. Just copy them from there, with all comments and documentation. Simply LOL. Why nobody is sueing ActiveState for this?

3. Using PAR even with --filter option produces rather readable code, that doesn't work most of the time for real projects.

4. Using perl2exe is questionable due to existnance of exe2perl (search on google for it). If it won't work for current version of perl2exe, memory dump of running process should do the trick and one will get cleartext of your scripts with comments and everything.

The only reliable and unreversable solution is the use of obfuscator - like Stunnix Perl-Obfus. Obfuscators replace names of variables and functions (and other names like names of file handles) with some random-generated identifiers (this is one-way function, it can't be reversed), also removing comments, white spaces and replacing strings and integers with expressions or their uglified versions.

.. or use a commercial Stunnix Perl-Obfus - obfuscator and encoder for Perl - instead.

For example, Stunnix sells Perl Obfuscator, JavaScript Obfuscator, C/C++ Obfuscator and VBScript Obfuscator. They have one more product though - Perl Web Server.

So, definitely there is a demand for obfuscation (perhaps due to a rise of scripting languages compared to compiled ones)..

Some commercial tools for unix (written in C) are also distributed in obfuscated source form, along with Makefiles to built with - for example Gimpel Software's FlexeLint for C/C++.

For example, Stunnix sells Perl Obfuscator, JavaScript Obfuscator, C/C++ Obfuscator and VBScript Obfuscator. They have one more product though - Perl Web Server.

So, definitely there is a demand for obfuscation (perhaps due to a rise of scripting languages compared to compiled ones)..

Some commercial tools for unix (written in C) are also distributed in obfuscated source form, along with Makefiles to built with - for example Gimpel Software's FlexeLint for C/C++.

For example, Stunnix sells Perl Obfuscator, JavaScript Obfuscator, C/C++ Obfuscator and VBScript Obfuscator. They have one more product though - Perl Web Server.

So, definitely there is a demand for obfuscation (perhaps due to a rise of scripting languages compared to compiled ones)..

Some commercial tools for unix (written in C) are also distributed in obfuscated source form, along with Makefiles to built with - for example Gimpel Software's FlexeLint for C/C++.

For example, Stunnix sells Perl Obfuscator, JavaScript Obfuscator, C/C++ Obfuscator and VBScript Obfuscator. They have one more product though - Perl Web Server.

So, definitely there is a demand for obfuscation (perhaps due to a rise of scripting languages compared to compiled ones)..

Some commercial tools for unix (written in C) are also distributed in obfuscated source form, along with Makefiles to built with - for example Gimpel Software's FlexeLint for C/C++.

For example, Stunnix sells Perl Obfuscator, JavaScript Obfuscator, C/C++ Obfuscator and VBScript Obfuscator. They have one more product though - Perl Web Server.

So, definitely there is a demand for obfuscation (perhaps due to a rise of scripting languages compared to compiled ones)..

Some commercial tools for unix (written in C) are also distributed in obfuscated source form, along with Makefiles to built with - for example Gimpel Software's FlexeLint for C/C++.

For example, Stunnix sells Perl Obfuscator, JavaScript Obfuscator, C/C++ Obfuscator and VBScript Obfuscator. They have one more product though - Perl Web Server.

So, definitely there is a demand for obfuscation (perhaps due to a rise of scripting languages compared to compiled ones)..

Some commercial tools for unix (written in C) are also distributed in obfuscated source form, along with Makefiles to built with - for example Gimpel Software's FlexeLint for C/C++.

Lucky PHP guys.. Too bad that support for compiling Perl code into executables is almost non-working.. The only viable alternative I know of is using Stunnix Perl-Obfus for obfuscation/scrambling, and turning output into executable with PAR or Perl2Exe. Does anybody knows a better alternative?

It would be nice to have such advanced thing for Python and PHP.

BTW, I found Stunnix Perl Web Server to be a nice foundation for cross-platform browser-based applications in Perl - it's advanced web server written in Perl aiming at providing smallest response latency possible, that can be packed along with perl-driven dynamic site itself into standalone executable that includes Perl interpreter (that, when run, will start web server on free port and open browser window with the site). Real alternative to Gtk and Qt, IMHO - at least for simple apps.

Another approach to web-based apps is to run web server locally, and implement application as dynamic web site. I've recently found a nice platform (based on Stunnix Perl Web Server) for writing cross-platform browser-based applications (using website construction technologies) for Perl. They ship sample app, and their demos, though essentially are dynamic website driven by Perl and served by web server written in Perl - works instantly, like native app - even on Celleron-466MHz on WinXP and linux. Also they claim it's possible to pack everything into single executable image with Perl interpreter embedded (they have a demos of 2MB in size!), running which you get server started and browser window opened.. No internet connection required of course (and no Perl interpreter needed too!). I like this approach - it's easy to develop powerful websites in Perl and it's very cross-platform.

OSS Community: Businesses should adopt open source software and get away from MS.

Business Guy: I'd love to if you just has [feature] which MS has and makes my life a lot easier.

OSS Developer: OK, that'll cost you $xxx

BG: OK, deal.

OSSD: OK, *hacks* done!

BG: Ooops, sorry, we don't want it anymore! No $$$ for you!

OSSD: Aw, poop!

--

Let's wish them good luck. Until the project completion, we will have to use expensive obfuscators like this one from Stunnix to hide our Perl source code..

Yet another reason to use Perl for mid-sized projects instead of Java, in cases when Java was sometimes chosen only because it was easier to hide the source code of the app/module by coding it in Java, - was recently eliminated by the introduction of obfuscators like Stunnix Perl-Obfus or similar ones. That's a very good news for us Perl fans. Let's hope Perl will be treated even more seriously by corporations when Perl6 will be declared stable..

with the availability of Stunnix Perl-Obfus - commercial obfuscator for Perl, this is solved now.

since when did perl need any more obfuscation?

The biggest problem of Perl compared to other popular languages like C++ or Java was that there were no 100% reliable tools able to convert perl source to bytecode or native code without ability of getting cleartext of source code - that lowered acceptance of Perl for commercial software. But IMHO with the availability of Stunnix Perl-Obfus - commercial obfuscator for Perl, this is solved now.