Are there any known delphi components or code that creates a simple virtual drive that links to a single file. example ISO file? but this time, can be read and write.
Writing a "virtual drive" requires writing a kernel-level device emulation driver (a "SCSI miniport"-based drivers seem fairly popular), which generally means C/C++ -- and that is just the start ;-)
Not a trivial task. There may be some existing [open source] code solutions that get at least some of the way there...
Here are what I have been able to find with some quick google goggles:
Wikipedia article on ISO software
WinCDEmu
WinCDEmu is an open-source utility for mounting ISO image files in Microsoft Windows. It installs a Windows device driver which allows a user to mount an image of a CD or DVD ROM and access it as if it were a physical drive.
TrueCrypt
Virtual Floppy
However, if all you need is a tool to create an ISO/VHD from a directory and not a real "virtual drive" (or, at least a virtual driver someone else is providing), then that might be a far simpler integration task...
Happy coding.
Related
We have developed a tool in python which uses many libraries and other algorithms. We want to give that to customers on premise through docker image. It works pretty well. However, if someone copies image and exports/extracts (export or save command), everything becomes visible that includes our python files and library (python) files as well.
Is there a way, we can protect our code such that customers can't export it or see anything inside the image? Is there a way whole image can be encrypted or locked? I believe obfuscation can help to an extent, is there an obfuscation tool that obfuscates whole project (all files and folders while not breaking references)?
The root user on the host machine (where the docker daemon runs) has full access to all the processes running on the host. That means the person who controls the host machine can always get access to the RAM of the application as well as the file system. That makes it impossible to hide a key for decrypting the file system or protecting RAM from debugging.
Since you are sharing the image, You got no way to protect it from copying.
However using obfuscation on a standard Linux box, you can make it harder to read the file system and RAM, but you can't make it impossible or the container cannot run.
Sometimes in s/w companies, customers provide data in multiple formats. There are linkable and executable data that are said to be "Rehosted" and compiled object files that are said to be "Retargeted". I am trying to understand what rehosting and retargeting mean in this area. Is it similar to the Bootstrap theory in computer science? I have the understanding of the following process (if not incorrect):
PROBLEM:
I need to write a compiler for a new language called "MyLang" to run on PowerPC
Solution:
1. I need to write a compiler for a language "MyLang-Mini"; a subset of "MyLang" to run on PowerPC.
2. I need to write a compiler for "MyLang" using "MyLang-Mini" to run on PowerPC.
3. I run the compiler obtained from no. 1 through the compiler obtained from no. 2 to
obtain the compiler for MyLang to run on PowerPC.
IN BESPOKE "T" DIAGRAM (...ISH):
MyLang PowerPC MyLang PowerPC
MyLangMini MyLangMini PowerPC PowerPC(instr.)
PowerPC(instr.)
What I am getting confused about is rehosting and retargeting. How are they coonected to this concept? What am I rehosting and retargeting if I have some binary data such as .exe or .obj? I would appreciate some detailed explanation if possible please!
I know that this will embark onto "CROSS-COMPILERS", but would prefer expert opinions to be sure.
Thanks in advance.
I now know that in s/w engineering:
REHOSTING - If you have a third-party application linkable/executable that requires usage on your host machine, you do rehosting. The target in this case are most often the same (OS platform, processor, etc.). In worst case, there is a virtualisation required. The rehosted application will run as if it was one of the application running in the host machine
RETARGETTING - If you have a third-party source code, you might need to recompile that to match with your target environment. It may also be that you have third-party .o or .obj compiled models and you want to link them with your source code (retargeted) in order to host it on a host machine. Just like REHOSTED application, it will be as if the application was installed on the host machine.
It will be good to know how this is similar to the compiler rehosting and retargeting. Sorry, I am a newbee is this area and will appreciate even a slap on the wrist.
Back in the days of Delphi 7, remote debugging was mostly ok. You set up a TCP/IP connection, tweaked a few things in the linker and you could (just about) step through code running on another PC whilst keeping your Delphi IDE and its libraries on your development PC.
Today, with Delphi XE2,3,4 you have paserver which, at least at the moment can be flaky and slow. It is essential for iOS (cross platform) development, but here at Applied Relay Testing we often have to debug on embedded PC's that run recent Windows. To do this we have employed a number of strategies but the hardest situation of all is to visit a customer site and wish that one could 'drop in' a Delphi IDE + libraries and roll up ones sleeves to step through and set breakpoints in source code.
It is quite likely - hopefully - that the paserver remote debugging workflow and its incarnations will improve over time but for now I got to wondering how it might be possible to install Delphi + libraries + our source code on a USB key so that with only a minimal, perhaps automated setup, one could plug that key into a PC and be compiling, running and debugging fairly quickly.
I can see that the registry is one of the possible issues however I do remember that Embarcadero once talked about being able to run their apps from a USB key. Knowing how much of a pain it is to install my 20-odd libraries into Delphi though, it is not trivial and needs thinking about.
Has anyone done anything like this or have any ideas of how it might be done?
Delphi does not support what you are asking for. But what you could do is create a virtual machine with your OS, IDE, libraries etc installed in it, then copy the VM onto a USB drive, install the VM software on the customer system, and run your VM as-is. There are plenty of VM systems to choose from.
First, I need to get this out of the way: embedded PCs running Windows?? Sob.
Ok, now for a suggestion: if a full virtual machine isn't an option for this task, application-level virtualization may be. This intercepts registry calls and other application-level information and maps them to a local copy, allowing essentially any application to be turned into a portable version. The good news is that there are free versions of several programs that can turn Windows programs into virtualized apps.
The only one I've personally used is MojoPac, and found it delivered as promised although was very slow running off of a (old, very slow) flash drive.
http://lifehacker.com/309233/make-any-application-portable-with-mojopac-freedom
I haven't used this newer "freedom" version though.
Two other programs I've seen that appear to be popular are Cameyo:
http://www.techsupportalert.com/content/create-your-own-portable-virtual-version-any-windows-program.htm
and P-Apps,
http://dottech.org/26404/create-a-portable-version-of-any-software-with-p-apps/
but I can't vouch for the quality of either of these two.
Hope this helps.
I am trying to do a series of tutorials to guide others on how to share a full development system to Unix running in VirtualBox. Oddly, the last piece of my tutorial (The Gimp) seems to be the only software that lacks a default Projects directory. Am I missing something?
I use Gimp on Windows and Ubuntu, but have never taken much notice until now of this. It seems pretty common for a software of this type to have a default directory to store projects to. Doing so, would allow directories to be shared between host and guest systems like in VirtualBox, but more importantly assist those that like to write scripts not just for themselves, but others too. eg. I can refer to ~/IdeaProjects in a script in confidence that the directory contains Jetbrains IDEA projects.
*This is a Gimp issue as it is both on Windows and Unix Gimp that have no projects directory.
No, it indeed does not have, and will just save to the system sugested (~/Documents, generally) just like OpenOffice, text editors, and a lot of other programs.
There are directories for the resources GIMP uses, like plug-ins, textures, brushes and so, which can be set in the prefrences dialog (and are stored in a ~/.gimprc file which can be parsed. But no default folder for user images.
Is it Possible to create bootable (Applications for MBR )application using Delphi or Pascal (I know we cant use vcl , RTL and other stuffs because they depend on OS), but can i use at least Readln and writeln.
If it is true !!! Can we run the program under other OS.
but i know that PE (windows) and ELF (Linux ) formats are different. but at least with some small modification can i do it.
It's worth saying that PE is a very diverse format than ELF.
Not only a few bytes to modify... the whole layout and library access is diverse, and binding is totally diverse.
In order to boot Delphi application in console mode, you can put a small DOS system (take a look at FreeDOS, for instance), then run your Delphi application using for instance DWPL. DWPL allows to run native 32-bit protected mode DOS programs with Delphi 5-7 using the WDOSX DOS extender as the core. I used this in some old hardware with a network adapter, and it worked like a charm. If you are interested in it, I could post some updated code of DWPL.
For such targets, you should take a look at Free Pascal. By nature, you can customize it to whatever target you want. There is even diverse draft Operating Systems written using FPC. See for instance Toro or ClassiOS - the latest uses Delphi executables as source.
You can see the boot code of Toro from here, and a "main program" source code created with it.
But for direct booting applications, booting is not so difficult. The real problem is the hardware layer.
The BIOS gives very little access to it.
Just for the network layer, you'll have to take a look at EtherBoot sites and such to get some low-level network access... but it could be very time consuming to rewrite all those drivers by hand!
In short: all those "pure pascal" OS are only theoretical, running a console and some low-performance network (emulating a poor network adapter like NE2000 or such). So those "pascal" OS are only proof of concept. FAR away from a working solution! But very nice technological challenge, in all cases, very inspiring.
Why reinvent the wheel? If you want a light and fast system, use a custom Linux kernel.
Then use CrossKylix to compile your Delphi application (with no User Interface) into Linux, or even better Free Pascal.
You don't really place "applications" in the MBR.
The entire size of an MBR is 512 bytes, of which you can only use 446 for code.
Good luck creating something useful in that if you don't even have an OS to delegate functionality to yet. Basically all that you can do in the MBR is place code to start a boot loader.
Here's a page with disassembly of an MBR:
http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm
Why must you write the boot loader?
You could use a ready-made bootloader like GRUB and chainload your PE executable, from it.
Of course, this is very ancient and hairy stuff, but in the good old days, people did this win PE format executables, and a DOS Extender.
For something a little more this-century, why not make your own bootable REACTOS disk, and add your own PE executable written in Delphi to handle the "user shell"?
You could also (but this would require licensing) use the Windows PXE. I think that projects like BartPE probably fall on the gray side of legal, or are at least, unlicensed. Thus, a completely MS-free solution (reactos) for a completely self-contained kiosk PC, with ReactOS, might be more what you are looking for.
Can you write your own operating system? your own UI layer? your own video device drivers? I didn't think so. So use DOS and TurboPascal, or ReactOS and a PE win executable. Or you can use FreePascal and just build your app on a very lightweight portable Linux kernel and root filesystem.