User forums > General (but related to Code::Blocks)

New unofficial installer for Code::Blocks available for testing!

<< < (2/8) > >>

Conan Kudo:
Well, my installer is NSIS.... However, I found a plugin for NSIS that allows webupdating simply by running the installer. Since the installer makes a registry key to the location of the file that uninstalls/updates it, it could be run with the update switch to request updates from the website. The code im using takes up 200k of the installer package, not 10MB.... However, I was including the MinGW toolkit with it as well, so there could be justification there, since the MinGW toolkit is 85MB is size, compared to the 70MB originally in the C::B 1.0rc2. I guess that would do it.... Well, i'm still working on the basic stuff right now, such as coding in parts that need to be registered, etc. The MinGW toolkit can be updated from the web updater component.... I'm just being careful right now... When I believe the code could work, then I will submit it... The code at the moment, is in barebones mode, which acts exactly like the existing installer. I plan to add in the other parts in a bit...

mandrav:

--- Quote ---I mean both... The devpak thing is a great idea
--- End quote ---

Nobody talked about devpaks. We talked about something "similar" to devpaks...


--- Quote ---but there is certain restrictions, such as the fact that it requires Code::Blocks to be running, so patching the actual program is out of the question, along with the DevPak plugin, etc.
--- End quote ---

Whether the new system will be a plugin or a stand-alone app is not decided yet.
Besides, even if it is a plugin, who says it can't update C::B if it's running? (yes, I 've done it before)

PharaohAtem:
We appreciate that you want to help, but I think what you 're trying to do will be of no use.
[*] about MinGW, you should know that it's not certain that the next release will include it.
[*] You seem to forget that C::B is cross-platform. Functionality that is offered for a single platform only (windows in your case) will not be accepted, ever (unless it's a plugin).
[*] I don't see a reason for a "patching system". The actual download is small enough (2-5 Megs) even for dialup users. It would only complicate things and, most importantly, would add one more possible point-of-failure.
[/list]

If you think I misunderstood what you 're trying to say, please clarify.
I just don't want you investing your precious time to something futile...

Conan Kudo:
Well, anyways, I don't think I can get the point across, so I will just not ever post it... However, I will work on it for my own purposes of learning the structure of C::B. It is quite true that it would only be for Windows, but my patching idea could be crossplatform! Someone would just have to write something that can handle the patches and verify them in a similar fashion to the way my installer would have done it... Anyone who understands what I am talking about may be able to know the benefits of it... Also, it may not be neccessary to have MinGW included in the web installer stub that is also created, which takes the latest versions of the program and pulls MinGW from the MinGW folder somewhere on the C::B site if it was implemented, or we would have to use similar coding of the MinGW installer to download the MinGW toolkit also... Although mine takes the approach of being able to hotpatch even running... I'm saying that updating C::B while it is running is out of the question because sometimes there are file locks, but you proved that you can do it? What the installer would do is "save state" then close C::B and update, and "restore state" afterwards...

Game_Ender:
This is where windows is behind the times.  On Linux and OS X you don't have to worry about "file locks" because there are none.  You could have CB patch itself and then when it reloads it will be using the new versions of the files.  Basically on *nix systems when you replace an in use file that file is kept in a hidden state for any programs that are currently using it, but any new attempt to access that file will result in the new file be used.  Much better than the heavy handed locking method windows takes.  There might be a way around this on windows but I am not sure.

Conan Kudo:
It is called state saving hotpatching. It has been around in *nix platforms for years, and Windows has to emulate it with certain types of installers... However, Windows Vista will have native support for state saving hotpatching. It is part of the Windows Installer 4.0 package system... NSIS does have systems to do hotpatching, but state saving hotpatching takes a lot of work to make it work properly. The installer I designed is going to be written with such support eventually, but *nix hotpatching style is already a part of the plugin that I am using. It also allows web updating, which may be a good idea to eventually implement. I can also build a web version which downloads the latest MinGW toolkit and builds an installer to wrap the toolkit in, and runs the installer. This way, Code::Blocks site bandwidth could be saved a little by using the MinGW repositories to grab files to build and start the C::B installer. It turns out that MinGW takes up nearly 95MB of space, so I have justification for that extra 10MB. However, I can easily remove the MinGW part of it and create web download of the toolkit, if it is going to be a real issue. Inno does not plan to have these features, so I made my installer script using NSIS from scratch because the conversion program for Inno to NSIS is not complete. It would not be necessary to make such a system in *nix platforms, so something like Code::Packs could be used on *nix platforms to update the core without causing problems, because problems with inprogram patching can occur without knowing it on Windows. Take for instance, RealPlayer. Its core has to shut down RealPlayer FIRST before updating, and even then, you have to "update" using the full installation procedure. My system would not require full install procedure, but it would do what RealPlayer does...

Navigation

[0] Message Index

[#] Next page

[*] Previous page