Delphi PasLibVLC - use without installing VLC player - delphi

In our application, I am trying to play a stream through the TPasLibVlcPlayer component (http://prog.olsztyn.pl/paslibvlc/). I succeeded in doing this, but only when VLC is installed.
The goal is to deploy the needed dll's with our application so we can use our application on a (Windows) pc that doesn't have VLC installed.
Question is: what do I need to do to make this work? So far I tried to put
libvlc.dll
libvlccore.dll
in a separate folder and deinstall VLC, then set the path to these dll's
PasLibVlcPlayer1.VLC.Path := 'C:\Tools';
However when trying to play the stream, nothing happens. I debugged and saw that the libvlc.dll is loaded (a handle is returned) and the needed procedures could be executed (GetProcAddress returns an assigned addres for all supported procedures), however when libvlc_new is called (inside TPasLibVlc.GetHandle), this returns nil.
Should there be other dll's in that directory or what do I need to do to make this work?

VLC is not a monolithic program.
VLC is a complex framework of different classes plugins and the database of those plugins, and the dispatcher to build the interconnected network of those plugins for every particular task like converting or playing a given source.
VLC is in the same league like GStreamer or Direct X ( the DirectShow/DirectMedia subpart of it ). Can you use Direct X framework without installing Direct X ? Hardly so.
Even the AceStreamer project that aims to turn BitTorrent into p2p online video streaming platform and is being coding it for few years already they still did not "copied few libraries" from VLC but rather modified its soures and made their own build of VLC player to use with their P2P-to-streaming proxy daemon. After all the years and with all the experience they had and gained.
Granted, VLC being Linux-originating is not dependent upon Windows means of installing, so if that is okay for your goal, you can install VLC in VLC terms but avoid installing it in Windows terms. To do it you would have to
take the zip (not exe) distro of the VLC (win32 or win64 - should be the same as your program platform).
create a folder where you would unpack the whole VLC to
after unpacking you would have to run vlc-plugins-cache-generator so it would enumerate all the plugins and create the database of its classes and implementations
then you would have to ensure all those files can be read and executed by mere user. Your installation would almost surely run under UAC-elevated Administrator permissions. That means by default all the unpacked VLC file including plugins DB would not be reachable by non-elevated or non-admin users of the computer. You would have to fix it explicitly giving users the rights to read/execute those files.
Then you would be able to call VLC functions from DLLs in that folder.
But personally I think the candles are not worth the game here and you better give your users the freedom to use VLC as they see fit and to upgrade it when new versions would be issued. Otherwise your program would most probably turn into a source of security problems for them.
Above points were made from a purely technical point of view. But there is another issue - legal.
Are you even going to DISTRIBUTE your program outside your office? As soon as you would pass any rights to your program from the original rights holder to a licensee - you would have to respect VLC team rights.
http://www.videolan.org/legal.html - note that little "most" word, when VLC team describe status of smaller software projects they integrate into VLC.
As long as you redistribute the non-modified VLC installation bundle - you are clean and safe. VLC team gave you explicit permission to do so. If anyone would consider VLC bundle having some pirated or otherwise illegal code - you are somewhat protected by "I did not know, I merely trusted them they do play fair" defence line. You are acting like a consumer when taking VLC installer for granted. Like a person who purchased a car in a shop. If later it would be revealed the shop was illegal and was selling hijacked cars - you would loose that car, but at least you would not go to jail yourself.
However as soon as you would make your own VLC packages containing selected parts of VLC you become VLC co-developer. You gain those "four freedoms" of FLOSS, but any freedom comes with responsibility. Now if "intellectual property" vultures would come to you, you would no more say "VLC did it", no. From this point it is YOU who did it.
And if some FLOSS project would claim VLC pirated their code (chances are very tiny, but hypothetically that is possible too, complex FLOSS project are assembled from hordes different small works (from libraries to snippets and bugfix patches) with different initial licenses, and it is responsibility of maintainer (that means now - of YOU) to check or negotiate re-licensing compatibility), you would be co-responsible for it after you abandon standard ready-made bundle.
And then there come that very "virus nature" of strict GPL license. When you use standard installer package you do not mix your code with VLC code. You just put several different installers into one media and you only use APIs explicitly published to be consumed by other software. But if you would rehash VLC into your own streamlined set of files - from that point on you are a co-developer not a consumer any more. So chances are one day you would be asked to disclose the sources of your application because you use LGPL/GPL sources of VLC and your program now should be distributed under the same terms, otherwise your distribution of VLC maybe become piracy, maybe not, you are free to stand for your point of view in public trial.
Would you like it ?
Those concerns do not apply to you in two cases:
You do not DISTRIBUTE your program, you only use it in-house. Then GPL/LGPL responsibilities are not affecting you, and for "intellectual properties" vultures you are mostly under radars.
You use standard unmodified VLC bundle as it is made by VLC team. Then you are not bound by GPL/LGPL either and any vultures would have to fight with the VLC team first before they may come to you claiming VLC is illegal software.
If those cases do not suit you then you want to become a co-developer of VLC and thus you do accept all the responsibilities of it. Just for small space gain. Are you ready for it? Are the candles worth the game?

Related

Is it possible to update NodeMCU Lua files OTA?

I would love to be able to update my NodeMCU ESP8266-01 OTA, since they're located in awkward spots. I'm by no means an expert regarding the ESP or NodeMCU, but I haven't been able to find anything recent about OTA updates. I found some discussions about it going back to 2015, but it never seems to have been implemented.
I use my ESP with NodeMCU to control a PWM dimmer. I upload a precompiled version of NodeMCU with the NodeMCU Firmware FLasher, and then use ESPlorer to upload a custom lua file called 'init.lua'. I'm not even sure if this is the proper way to do stuff, but it works.
So the main question: Has OTA updating been implemented, or is it possible in some way?
Just to clarify, I don't think I want to update the firmware. As I understand it, firmware is what you build yourself, or on a website like https://nodemcu-build.com. I want to update the lua files that run on the ESP, that you normally upload through a program like ESPlorer.
I found some discussions about it going back to 2015, but it never seems to have been implemented.
Indeed, firmware OTA is not available yet. However, as you probably know, the need for firmware OTA is much lower with the NodeMCU firmware than e.g. with the Arduino platform. I'd argue that you're much less likely in need to replace/upgrade/extend the firmware with its built-in modules than the application code that runs on top of it.
Fortunately, it's quite simple to replace one or several Lua scripts (compiled or uncompiled) on the device and reboot it. All the web and cloud IDEs listed at https://frightanic.com/iot/tools-ides-nodemcu/ offer this. There's even a pending PR that'll bring FTP support to NodeMCU.
For a complete Lua provisioning system take a look at what #TerryE provided at https://github.com/nodemcu/nodemcu-firmware/tree/master/lua_examples/luaOTA
I've attempted to use the two Web IDEs listed in the link provided in Marcel Stör's answer, but I honestly failed to understand how to use either IDE. they also seemed like they weren't exactly what I was looking for, and required a server to connect to, or an extra program, which I wanted to avoid.
Edit: Apparently, I did end up using one of the two Web IDEs in the list. Since it's been a while since I did all this, it's a bit fuzzy in my head.
I eventually stumbled upon this GitHub page, which seemed to provide exactly what I was looking for: The ability to access the Lua files on the ESP through a webbrowser. I have personally changed the ide.lua file around completely, since I needed to call functions from it in the init.lua script. However, I think you can just upload the ide.lua script to the ESP, and add a line containing dofile("ide.lua") to your init.lua file.
If anyone is interested in my changes to, or my implementation of the ide.lua script, you can take a look at my repo Timmiej93 / QuinLED / Program code.
In fact there's a class for that to implement OTA i the NodeMCU its called the ESPhttpUpdate you can refer to ESPhttpUpdate for further details.

Updating own software in Program Files

I have a single executable which, via InnoSetup, installs into Program Files\FolderName by default. The exe has a 3rd party component which goes online to check for new versions and downloads them, then does a bit of fiddling to replace the exe - simple stuff. The problem is, it can't do this in Program Files because of the necessary security there. I was reading Windows 7 - Can't update my program's files in C:\Program Files in which David Hefferman gives a solution but then seems to say it's a bad idea - but I don't know whether the bad idea bit refers to his solution or to the OP's comments!
So what is the preferred method by which a program can update itself? One that will work on XPSP3 to Win8. I can't seem to find the right phrase to enter into Google that gives me relevant results. Ignore digital signatures and suchlike for now, for simplicity.
(Please note, it may look like I worded that as an opinion question but it's not - there must be some MS-endorsed way of doing it that I can't find. FWIW this is a Delphi program but any Win32 notes will do)
That 3rd party update utility needs to be run with administrative privileges, you can achieve that programmatically.
There is nothing wrong with installing your application in Program Files, that is the designated purpose of this folder. However, user data that is used by the application should be stored in a different location.
However you run that 3rd party Utility, you should first check the Windows OS version to see if fiddling with UAC is really necessary(Vista+...) and then run the utility in the elevated state.
He says its "extremely bad practice" to fiddle with your system so that normal users can write in "Program Files".
If your program is in "Program Files" it's installed with System Admin rights. So updates need also be installed with System Admin rights.
You can configure InnoSetup to request admin-rights so you can write to "Program Files" but if the 3rd party component does not do this its best to install everything in an other directory.
i.e. C:\Your_Program
That way your 3rd party component can write there.
There are several options here:
The easiest: make updater as a separate program with manifest, which requires admin privileges. Also you can ask for admin privileges when you start your updater. Or you can move your updater into out-of-process COM object instead of separate exe.
You can create hidden user with admin rigths during installation of your program. Then you will run your updater with credentials of this user.
You can install system service during installation of your program and this service will run from system account. So your updater will be implemented as a service.

Building VB6 projects without registering

We have an old VB6 project that uses ActiveX controls, some of which we build and others we get from third-party vendors.
Currently, we use a .csproj project which does the following,
Execute regsvr32 to register the OCXs
Execute vb6 to build the VB6 project
Execute regsvr32 to unregister the OCXs
This registering/unregistering is ugly and is a bit of a pain for local developer builds with UAC enabled. Is it at all possible to build a VB6 project without having to register any controls?
I apologize if this has already been asked before. The only similar questions I was able to find were about how to build VB6 projects, and answers to these mention the same solution of register, build, unregister.
It sounds like these people are merely working on clients of these OCXs rather than modifying and recompiling the OCXs themselves.
If so, you should be administering the installation of these libraries just as you administer the VB6 development system itself. This means each workstation needs to have the control suites you are using installed once (well, and maintained when new releases are placed into use). Installers for developer libraries deploy things like .DEP files as well as design-time license key registry entries, so using regsvr32 shouldn't be considered a viable strategy anyway.
If you set the developer workstations up properly and maintain them there isn't any reason to be registering and unregistering such things.
It means the original developers probably did not set the "binary compatibility" correctly. Which means the VB6 dll's get a "new com guid" every time they are built.
Which means your original VB6 developers were probably a bunch of hacks.
You can read the section here on Binary Compatibility.
http://support.microsoft.com/kb/161137
Get in a time machine and go back and punch the person in the face who said "We don't need
to work out the binary compatibility issues now, we'll just unregister and re-register the components... Easy Peezey!"................
If I'm wrong, please let me know. But every time I've seen "unregister the com" and "re-register the com".........it goes back to that brainiac decision.
Here is a longer discussion on it:
http://www.techrepublic.com/article/demystifying-version-compatibility-settings-in-visual-basic/5030274
EDIT:
If the ocx's are not changing........then you should only have to register them once on the build machine once.
The direct answer is no, it is not possible to compile a VB6 project with OCX dependencies without those dependencies being registered.
Furthermore, the act of compilation itself involves VB6 attempting to register what it has just built (unless you are compiling to an EXE). This generally requires the VB6 IDE and/or its compiler to run with "admin" permissions. Therefore the permissions are a hard to avoid issue regardless.
I believe these issues can be obfuscated by the fact that VB6 itself (the IDE and/or the runtime) will sometimes try to automatically register certain things for you, but will keep silent when it does so.
You should probably create a different process to setup a development PC from the build process you use from deployment. This may "feel" wrong especially if you have experience with other programming environments, but I would stress that VB6 can be very painful & problematic to work with and so pragmatism is generally in order.
On the development PCs: Setup all the unchanging dependencies once (and document them) and then leave them alone (as noted in another answer.) When weird dependency problems occur, verify the PC is setup correctly before doing anything else.
If you have all the sources to your dependencies, then I would consider if you can actually run them all in a VB6 project group (VBG) and not compile them at all. (A VBG is akin to a .NET solution though far less powerful.) I do this often and it cuts out a lot of wasted time. Developers don't necessarily need code compiled to EXE / DLL / OCX - they often just need to be able to run it in the IDE.
On the build PC: If you can always start with a clean environment, like in a virtual machine, then I think its actually a good idea to register everything from scratch in an automated fashion as this helps to verify nothing is missing or mismatched. Re-using the same build environment without doing this can mask problems when some dependency has changed in source control but still exists on the build machine. On a VM generally permissions aren't a limiting factor.
Notes:
If you are building an EXE, VB6 does not require any elevated permissions, as far as I can recall.
Running code in the VB6 IDE does not either.
[Caveat 1]:
It may technically be possible to create a side-by-side application manifest file for VB6.exe itself and include in that manifest whatever dependencies you need, thereby avoiding having to register them.
But this would fall well outside of the normal ways to use VB6 tools - its a hack - and possibly is not worth the potentially large effort. I don't think I've ever seen a working example and so I don't recommend this as a practical solution, but mention it for completeness.
Maybe in some locked-down corporate IT scenario this could pay off... maybe. In that scenario doing dev work in a VM might be a better option though.

Copy Delphi Profile

My computer crashed recently. We have a Delphi app that takes a lot of work to get running.
One of my co-workers has it all installed still. Is there a way to copy the stuff stored in the palette? And the library paths?
I am using Delphi 5 (I know it is very very very old)
That information is stored in the Registry. I don't know exactly how Delphi 5 does it, but try looking for a key called HKEY_CURRENT_USER\Software\Borland\Delphi\5 or something like that. You'll find all the registration information under that key, including a list of installed packages. You can export the keys to a registry file, copy it to the new computer and install it.
Standard disclaimer: Mucking around in the registry manually can be risky if you don't know what you're doing. Be very careful, and if this solution causes your computer to crash, your house to burn down, or demons to come flying out your nose, it's not my fault.
Try CNWizards which has an export functionality for your IDE settings. You can use the same tool restore them on the new machine. We use it to get the same settings on every development machine. In that way we can ensure that all builds are the same, regardless of who built it.
Based on my experience of having done this a few times(!), the most important registry keys are:
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Known Packages
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Library
and possibly
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Known IDE Packages
and maybe
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Palette
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Palette Defaults
So long as you have done a standard D5 installation first.
It's easier/more reliable to let the IDE fill in the other bits as you start using it and you change options as appropriate. Some component packages, eg madExcept, DevExpress etc are often best re-installed using their own installers anyway.
Unless you're going to have multiple users on the same machine using Delphi then the HKLM stuff isn't really all that important - I don't think.
As a related aside - I have learned that a good way to handle this is to build a FinalBuilder script (or similar) to set up my Delphi environment each time I decide to use a new machine/installation. I copy/download/checkout (which can be done in FB too) all package source then use FB to compile it, copy it, create dirs, and fill in the appropriate registry keys etc. I always get a consistent environment and makes it much easier to rebuild individual components or packages as and when they get upgraded too. The items can also be put into the script in 'dependency order' so that you know to re-compile a dependent package if something else changes. I now have a single FB sciprt that builds D5, D2007, D2009, D2010 environments and packages of all my main components, all depending on which compiler(s) I'm interested in which I indicate by a simple variable. Well worth it.
Seems to have just worked for me on a Win 7, SP1 and Delphi 5
Logged as user with Delphi & 3rd party components installed.
registry export
hkey current user\software\borland
(no other borland products so selected Borland)
rather than Borland\Delphi\5.0)
Logged into pc as new user.
Did not start Delphi5 (i.e. never started for this user).
Regedit File, Import
Started Delphi all components, including lots of 3rd
party, present.
Project compiled as expected under new user.

Is it possible to create a custom distribution of OpenOffice, or a way to package it into my java application?

I've got simple java-based ppt->swf sub-project that basically works. The open source software out there, OpenOffice.org and JODConverter do the job great.
The thing is, to do this I need to install OO.o and run it in server mode. And to do that I have to install OO.o, which is allot of software (~160MB) just to convert the source PPT files to an intermediate format. Also, the public OO.o distributions are platform specific and I'd really like a single, cross platform set of files. And, I'd like to not interfer with a system's current settings, like file extension associations.
As things are now, my project is not particularly 'software distribution friendly'.
So, the questions are:
Is it possible to create a custom distribution of OpenOffice? How would one about this?
How lightweight and unobtrusive can I make the installation?
Would it be possible to have a truly cross platform distribution since there would be no OO.o UI?
Are there any licensing issues I need to be aware of? (On my list of things to check out, but if you them already then TIA!)
I have no idea to accomplish such task, but Microsoft has its PPT viewer that is for free and very small, maybe in .NET (C#) you can use some kinda function to save into a intermediate file that you need...
and by the way, how are you handling slide transictions?
I found a software that does that but you need MS PPT installed.
this was just an idea, now regarding your actually question:
you can create your own installation of OO, just jump to the Installation project and follow the lines.
I did not read 'til the end, but from the 1st paragraph it seams what you are searching for.
No, not unless you are neck deep coding in the OpenOffice project.

Resources