Xplorer2 vs xyplorer code#
Xplorer2 vs xyplorer license#

In addition, it may be easier to program but it's definitely isn't easy in finding ways to work around some of the limitations when working on newer Windows which he works on all the time to make sure there are no problems while still being able to add new stable features including features for the scripting capability of the program. However it does not take away from the developer of what he was able to accomplish in making XYplorer still feel a very viable alternative file manager.

Xplorer2 vs xyplorer code#

The fact that Opus is doing it like it is (constant updates with pure and modern C++ codebase) is a testament to both Opus' quality of code which is obviously easily maintainable (otherwise it would be impossible) and GPSoft's dedication and love for the product (otherwise they'd give up like authors of most file managers did). Which is evident with xplorer2 which is stuck in the past and is barely moving at all with new updates for years now.

Xplorer2 vs xyplorer license#

I don't want to badmouth it, I had a license and used it in the past, all I can say is that it's obviously difficult and time consuming to develop new features the hard way in pure C++ without frameworks. While it is made in C++, last time I saw on their forums it is developed and compiled with Visual Studio 6 which was released in the year 1998. since when is the pure C++ code without any frameworks bloated There are no sacrifices and no compromises: Opus is made the hard way (which is the only right way) to achieve both modern look and modern performance.

This is why Opus can both look as stunningly as it looks and work as fast as it does. Look how polished its GUI is and all this is achieved without any GUI frameworks - it's pure Win32 API - as lowlevel as it gets (short of assembly code, but compilers today optimize C++ better than hand-made assembly). On the other hand, Opus is made in pure C++ and runs directly as a native machine code. The problem is the fact that VB6 applications are ran inside a tiny virtual machine: msvbvm60.dll (Microsoft Visual Basic Virtual Machine 6.0) which is a legacy 'engine', and as time passes it will get more and more isolated and abstracted from the real OS so that Microsoft can keep it working for compatibility reasons, similar to how DOS application compatibility was maintained for a while, with each subsequent version of Windows those legacy apps retaining less and less functionality, and then dropped entirely. I'd say it's not the VB6 itself as a language that is the problem for XY today.