I've got two questions about LÖVE.
Can I sell what I make in LÖVE? Can I compile anything I make into an EXE file?
Yes, you can sell what you make in LÖVE. Their site clearly says: "LÖVE is licensed under the liberal zlib/libpng license. That means you can use it freely for any purpose — including commercial ones."
And yes, you can make an executable out of your LÖVE project. Just see here.
Here's the answer to your EXE file question from their wiki:
Windows
copy /b love.exe+game.love game.exe
Linux
cat love game.love > game
From their TOS:
Permission is hereby granted, free of
charge, to any person... to deal in
the Software without restriction,
including without limitation the
rights to use, copy, modify, merge,
publish, distribute, sublicense,
and/or sell copies of the Software,...
subject to the following conditions:
The above copyright notice and this
permission notice shall be included in
all copies or substantial portions of
the Software.
It says you can do anything you want with it as long as you leave their permissions notices in-tact on any files they put it on.
From the same page -
Two things should be noted:
The end result will not be a single executable, you must also include some DLL files in your zip-file.
The resulting executable from the merge will still be readable by archiving software, such as WinZip.
yes, you can sell the games for any price
yes, you can compile them into .exe files through
copy /b (love.exe file location here)+(.love file location here) game.exe for windows and
cat (love.exe file location here) (.love file location here) > game.exe for linux,
in the folder where you put .exe file be sure to copy/paste the .dll files into said folder
Related
I have installed Luadist and created a small program (named abcd.lua which also uses IUP GUI). It runs well with command iuplua.exe abcd.lua I want to give it to some other persons to try. Since Lua may not be installed on their computer, I want to give it to them with Luadist folder. I see that there are a large number of files in Luadist folder (1148 to be exact- tried listing them here but it exceeds character count). They are in following folders:
bin : has large number of exe and dll files.
include: has lauxlib.h luaconf.h lua.h lua.hpp lualib.h
lib: has liblua.dll.a and its extracted folder and a lua folder with large number of subfolders and files
share: also has large number of folders and files.
tmp: only empty cache folder currently
Following files contain 'iup' in their names:
./share/luadist-git/dists/iup-3.6
./share/luadist-git/dists/iup-3.6/dist.info
./share/iup
./share/iup/README
./share/iup/COPYRIGHT
./lib/lua/iupluaimglib.dll
./lib/lua/iuplua.dll
./lib/lua/iuplua_mglplot.dll
./lib/lua/iupluacd.dll
./lib/lua/iupluacontrols.dll
./lib/lua/iupluagl.dll
./lib/lua/iuplua_pplot.dll
./lib/lua/iupluatuio.dll
./lib/lua/iupluaim.dll
./bin/libiuptuio.dll
./bin/libiup_pplot.dll
./bin/iuplua.exe
./bin/iupview.exe
./bin/libiup.dll
./bin/libiupgl.dll
./bin/libiupcd.dll
./bin/libiupim.dll
./bin/libiupimglib.dll
./bin/libiup_mglplot.dll
./bin/libiuplua.dll
./bin/libiupcontrols.dll
Will giving only these file alongwith my program file (abcd.lua) be sufficient, though I think many dll files will also be needed?
Which files or folders can I select to give or do I need to give all files for proper running of my program? Thanks for your help.
In the IUP documentation, each library describes its dependencies. You can start there.
But the answer depends on what modules are you using. If the only "require" you do is "iup", then it is quite simple. You will need the executable, the Lua DLL, the IUP DLL and the IUPLUA DLL.
You have a couple of options:
(1) move the executable to a different folder and start your script. It will fails with an error message about a missing DLL; move the DLL to the folder with the executable and repeat. This should give you a list of the dependencies, assuming the execution will follow all code paths that load external modules.
(2) use the dependency walker to find all dependencies that your executable and its DLLs have. The advantage of this method is that you can execute it without moving any files and it will give you a detailed analysis of the dependencies and how they are resolved on your system.
Keep in mind that you don't need to preserve the same structure that LuaDist has for the dynamic libraries; you can put all the DLLs your script needs next to the executable (and this is likely to be the simplest and the most successful configuration).
I want to make a program that opens two different programs (one virus file that infects the computer and one that is the real program). I have tried with .bat files, but it requires me to write the path to the file that includes the name of the targets user account. The problem is that i don't know what the target has named his account. Is there any way a program can search the sub folder and find the target programs automaticly? (Im planning on having that program with the folder "first" and in that folder the virus and the actual program will be)
Sorry for bad English
You can use Veil-Framework or metasploit to embed a payload into a file, and it accepts several different formats. Then you have to use social engeenering to distribute the infected file. Youll have to do some tests in local to ensure that infected file evades antivirus (the av evasion is the hard thing to do here as signatures of known payloads are also known by av software).
Renember that infecting a remote computer not owned by you can be considered a delictive act an can get you into legal issues.
Hope this helps.
The software that I have found myself supporting, from time to time fails to run on different PC's. Generally they are new Win7 installs.
The error message is "this application failed to start because rtl90.bpl was not found..."
To rectify the problem I have out PC Support copy the rtl90.bpl file to the users system32 directory, however i would like to ensure this error no longer occurs.
I have googled and found the followling link rtl90.bpl problem
My question is this:
The option to "Build with runtime packages" is already selected under the Project options for this program, and does not appear to make any difference to the users getting the problem.
Do I have to specifically Add the missing rtl90.bpl file to the project?
Please note that I know very little about delphi programming.
Since you are marked the option Build with runtime packages in your project, the final exe will require be deployed with some additional bpl files. To avoid that dependencies you must uncheck that option y build your project. Now your exe wil be bigger but without dependences.
That package is a runtime package containing the VCL. You presumably also need to deploy rtl90.bpl for the RTL and possibly some others. By enabling runtime packages you are promising to deploy those packages where the executable can find them.
You have 3 main options:
Deploy the packages to a location that is contained in the PATH variable. Usually this means modifying PATH. You should never write to the system directory. It is owned by the system and you should respect that.
Deploy the packages to the same directory as the executable file.
Disable runtime packages and therefore build a single self-contained executable. The RTL/VCL code will be statically linked into your executable.
Option 1 is poor in my view. Relying on the PATH variable and the ability to modify it is fragile. Option 2 works but seems rather pointless in comparison with option 3. You deploy more files and larger files when you choose 2, so why choose it.
In summary I recommend option 3. Statically link all RTL/VCL code into your executable.
The only situation where option 2 wins, in my view, is when you have multiple related executables that are all deployed to the same directory. In that situation sharing the RTL/VCL code can make sense.
i can use the copyfile(); function to copy a file to c:/windows/system32 on windows xp but then i use the function on windows 7 i cant copy it:o the file wont come there....
i had the same problem with writing and reading registery but fixed it by declaring a WOW key $0100 ...
i think the problem is uac but not sure.. could somebody explain me that:D?
That is indeed because of UAC. It is called File/Folder or Registry Virtualization. It is done for legacy applications who don't yet respect the new UAC rules (e.g. not writing in system folders unless you are an administrator).
By creating a manifest file you switch off this virtualization. See here. This can be a seperate file or be embedded into the exe. Newer Delphi versions already generate executables containing such a manifest and have requestedExecutionLevel set to asInvoker. This normally does not allow writing in those locations, unless users specifically run your program as an administrator. Setting it to requireAdministrator does allow writing in those locations, but also means users have to confirm they want to run your program as an administrator.
It's indeed UAC that's preventing you from copying files to the system32 folder. You have to ask yourself why you want to copy files there. A normal application should never copy files to the system32 folder.
Sometimes during install you might want to copy dll's there, but even that is legacy behaviour. Should you really want to copy files there, you should request Elevation at the start of the application.
Why are you copying files there? It should be treatead as the OS private directory. Unless you're installing a driver or the like, you should never write there. In XP you can only because you're running with Administrator privileges, try to use a plain user and you can't as well (since at least 2000, if not in NT already), but it will give you an error because it won't redirect the write. Unless you have a truly good reason to write there, I'd suggest to redesign your application to write in the proper place, instead of trying to find a way to write there. Anyway, it will fail anytime the user don't have the privileges and can't perform an elevation.
This question is similar to this one, but not a duplicate because I'm asking about issues not discussed in that question.
I have a client-server project in Delphi 7 with the following directory structure:
\MyApp
\MyClientApp
\MyServerApp
\lib
There are 2 actual Delphi projects (.dpr), one each in the MyClientApp and MyServerApp folders.
The lib folder has .pas units that have common code to the client and server apps. What I'm wondering is if I should include those .pas files in the client and server projects? Or should I create a package in the lib folder which includes those units? Or should I just leave the .pas files sitting in the lib folder and not add them to any app/package?
What are the pros/cons of each approach? Which way is "best"? Is there any issue with having those units from the lib folder be included in more than one project?
Right now the units in the lib folder are not a part of any app/package. One disadvantage of this is that when I have my client app open in Delphi, for example, and I want to search in all files in the project for something, it doesn't also search in the units in the lib folder. I get around this by opening those units and doing a find in all open files, or using grep search (but I'd prefer a better solution).
I would also greatly prefer a solution where I will not have to go and open some separate package and recompile it when I make changes to those files in the lib folder (is this where I should use a project group?).
Sharing units between applications always carries the risk of incompatible changes done in one application that breaks the other. On the other hand, making copies of these units is even worse, so your approcach of moving them to their own subdirectory at least adds a psychological barrier to changing them without considering other programs.
As for adding them to the project files: I usually add some units which I frequently access (either for expanding or for reference) from the IDE to the project, and leave others out for the compiler to pick using the search path. I do that on per project basis, that means, some units may be part of several projects, why not?
Putting them into a package only makes sense, if you actually want to create a package based application, otherwise, why bother?
For more info on how I organize my projects and libraries, see http://www.dummzeuch.de/delphi/subversion/english.html
I dislike having files shared by projects. All too often, you'll be tempted to edit one of the shared files, and you'll either break something in the other project, or you'll forget that you have to rebuild the other project at all.
When the shared files are instead separated into their own library (package), then there's a little extra barrier to editing them. I consider that a good thing. It will be a light reminder that you're switching from project-specific code to shared code. You can use project groups to let you keep every together in a single IDE instance. arrange the library projects ahead of the executable projects. The "build all" command will build everything in order, starting with the first project.
Keep your DCU files separate from your PAS files. You can do this easily by setting the "DCU output directory" project option to send your package's units to some other location. Then put that destination directory on your other projects' "search path." They'll find the DCU, but they won't find the PAS file, and so no other project will accidentally recompile a unit that isn't really a member.
Having a separate package also discourages use of project-specific conditional defines. Those cause all sorts of trouble when you're sharing units between projects. Find a way to instead keep all project-specific options within the respective projects. A shared library shouldn't require project-specific modifications. If a library needs to act differently based on who's using it, then employ techniques like callback functions that the library user can set to modify the library's behavior.
I would need to have a very good reason to add shared code to a package. If you just have a few shared files stick them all in a directory called Shared. This should make it obvious the files are shared between projects.
Also use a good build tool to do automated builds so you will find out soon enough if you break something.
.bpl files are fine for components, but bring in serious added complexity for things like this, unless you have a huge amount of shared files.
I usually create a package with all shared unit, and just use the units.
If you do not explicitly mark "Build with run time packages" the package content (all used dcu's) will be linked to your project as any other unit.
I would only use runtime packages if you actually had two binaries that were supposed to run on the same physical machine and that shared some code. Keep in mind that runtime packages are mostly an all-or-nothing approach. Once you decide to use them you will also no longer be able to link the RTL and VCL units straight into your projects and will instead have to deploy those separately as well.
However, packages might still be a good solution to your problem when combined with project groups which is exactly what I'm doing. I hate having shared units included in multiple projects. Including the shared units in a package (but not compiling your actual projects with runtime packages) allows you to add that package to your project group so you (and the IDE!) will always have them easily accessible yet nicely separated from the project-specific code. Strictly speaking you don't even ever have to compile those packages. They can merely serve as an organisational unit in the project manager.
Note that for the Find in Files, you can also specify "in all files in project group"