Yes, but you must adhere to Unix philosophy : You jus DON'T put the files wherever you want; one of the nice things about unix is that you KNOW where everything is !

If everybody starts craeting packages that install themselves God knows where, we're right back on Dos and Windows.

This is the very reason the File Hierarchy Standard was created; so you KNOW where to put your files.

So in that respect, RPM does it's job quite well;

I agree, though, that a nice user interface is badly needed, If only to make the user more comfortable, and give him the feeling he's got some control over the process. I continuously have troubles finding out what an RPM contains, what scripts it'll run etc.
Usually it boils down to downloading the sources and doing everything myself, so I'm in full control. But then, this is not really an option for 99% of the people, hence RPM is a good idea.

Just my thoughts.

Michael.

While I totally agree because the space business is a real pain and it causes problems as we have seen. Be that as it may it is there, it is used, and we will have to deal with it because it isn't going to change anytime soon if at all ever. :-\

forcing

Well, if not a marketing decision, then at least a dirty hack. The only "good" thing about it is that is didn't break backwards compatability for more than 25% of apps ;^)

Jeff.

Cliff Baeseman wrote

I think bill did that to cause the command line dudes problems thus forcing us towards windows.

You can be sure he did: On Unix, spaces in directories are allowed, but one simply doesn't do it, since unix is/was command-line oriented.

If you know how 'long file names' are implemented on FAT systems you'll understand that this MUST have been a marketing decision, technically it's the biggest shambles I've ever seen.

Michael.

Oh I agree. Where I have a problem with it is usually when installing source code and not binaries. When it is binaries I like that it puts it where it wants it and things work. With source code I usually want to put it in some out of the way place where I keep my source code for messing around with. I don't always like were RPM is setup to put source code. That is when I'd rather use tarballs. So what I am looking for is some sort of middle ground, flexibility when it is allowed but ridged control when required.

Usually it boils down to downloading the sources and doing everything myself, so I'm in full control. But then, this is not really an option for 99% of the people, hence RPM is a good idea.

And until it can satisfy a large portion of those 99% of people Linux will always just linger on the fringe of acceptability.

I think FPC and Lazarus is one of the big steps across that fringe.

Greetings,

I have finished and tested a Windows Installer of the download package that Cliff put together. It is SOOOOO easy that any one can now install and see what is what on the Windows platform. It is completely point and click. It also has an uninstaller so you can get rid of it at a later time.

1. It updates your autoexec.bat so that your machine knows where FPC has been installed.

2. It automatically edits and modifies the ppc386.cfg file to reflect where you have installed FPC.

3. It places all required DLLs into the appropriate Windows System directory.

4. It installs FPC and Lazarus code.

NOTICE:

Due to a current limitation in the linker, the path to which you install FPC must NOT contain any spaces. So in other words do not attempt to install it into c:\program files\pp.

As long as you don't use a directory with a space in the name you can now install it to any drive and any directory and it will work right out of the box.

Unzip the file you download to where ever you wish. Then run the setup.exe program and just follow the directions.

After the installation is completed, it will ask you to reboot the machine. This is due to the fact that your autoexec has been modified. You can reboot at this point or wait until later. However, you can not compile with the .bat files until you reboot.

Go to the source\lazarus directory. Double click on LazBuild.bat or HelloBuild.bat. The first builds Lazarus as it stands and the second builds the Hello_World example.

Thats it.

After you download you might want to retrieve the latest compiler snapshot and the latest lazarus code as indicated in a previous email from Cliff. Just download and copy those files into the same directories that you find them currently. That is all you have to do to keep up with the latest compiler and code.

So now where do you get you ask. Since the file is of some size 4,318,327 bytes I have uploaded to some space available to me on my ISPs server. This site has T1's and T3's so you should be able to download much easier if you have a fast connection. The URL is:

http://www.epix.net/~miraclec/fpc_win32.zip

Please let me know if someone has a problem with the installer so that I can make modifications before the next build.

d0hb0y wrote

ps: Wise will convert long pathnames to short path names for you, if you want. The question is, then, will the compiler run correctly if you tell it to use progra~1 instead of "program files" ...

The problem isn't the installation the problem is the linker. When you run the FPC the compiler creates a file link.res which contains commands and references used by the linker to actually create the application. However the compiler places long files names that might have spaces such as "c:\program files" in the link.res commands but the linker doesn't understand those long file names with spaces and fails the link.

If that can be modified in the compiler then the problem goes away.

Due to a current limitation in the linker, the path to which you install FPC must NOT contain any spaces. So in other words do not attempt to install it into c:\program files\pp.

ps: Wise will convert long pathnames to short path names for you, if you want. The question is, then, will the compiler run correctly if you tell it to use progra~1 instead of "program files" ...

I think bill did that to cause the command line dudes problems thus forcing us towards windows.

"Marketing Deal!"

;)

Cliff

http://www.epix.net/~miraclec/fpc_win32.zip

you cant distribute it as a self-extracting exe file?

:-)

I sure hope so. In the early days of Free Pascal (version 0.9.6, ages ago), I wrote a graphical installer that worked on X-forms. Worked pretty good; maybe I should dig up the sources somewhere once more.

Michael.

d0hb0y wrote

> >http://www.epix.net/~miraclec/fpc_win32.zip you cant distribute it as a self-extracting exe file?

It is. I made it a zip for 2 reasons. It includes a readme.txt files along with the setup.exe to give some a little headsup as to what this setup.exe is all about. Second if it is setup.exe some browsers see the .exe and try and run it or ask about running and just make the process more confusing.

It is a complete installer built using Wise. :-)

All my developer stuff is stored in \dev (no relation to unix's \dev :) .. and all my apps are stored in \apps .. so it wouldnt affect me anyhoo. I never did understand microsoft's obsession on "Program Files" ... its dumb. They might as well have named it "Subdirectory Containing Program Files" ... :-) "Programs" or "Apps" or something makes much more sense. Oh well.

== Ron

d0hb0y wrote

I just ran it, it looks very nice! :)

Great!

I'm just a picky S.O.B. so dont take it personally :-)

None taken. :-)

Wise is extremely powerful, yet not as wacked out as InstallShield. I love it.

I've been using before anyone ever even heard of them, when they were just a small shareware product. It makes InstallShield look like a joke with what you have to go through to make an installing using it. I just converted the company I am doing some work for. They were using InstallShield and when I put my copy of Wise on the machine and built a new install in 10 mintues which matched something they took days upon days to do they walked over to another desk and placed an order on the spot. :-)

Which brings up a good point, I have yet to see a "good" install mechanism for Linux... maybe one can be written someday in Lazarus :)

There has been alot of discussion going on on the Gnome mailing lists about this very subject. The general opinion is that it isn't needed and that are more trouble then they are worth. I myself disagree. While RPM does do the job to a point it is far from user friendly and just having a nice frontend to RPM still doesn't totally do it. At least I haven't seen one yet that does. The big argument was that they felt that an installer shouldn't let a person have a choice of where they want their files. It should put them where it wants to put them. That is basically what RPM does and why I don't totally like it.

So to that end, yes, maybe a nice installer could be built using Lazarus. That would be very fasionable. Not only a problem that you can write once and compile on different platforms but being able to use the same installer on different platforms as well. Potential.

I just ran it, it looks very nice! :)

I'm just a picky S.O.B. so dont take it personally :-)

Wise is extremely powerful, yet not as wacked out as InstallShield. I love it. Which brings up a good point, I have yet to see a "good" install mechanism for Linux... maybe one can be written someday in Lazarus :)

This is exactly what I do and have done with any application that I have developed. However in those cases I am delivering an application. In this case we are delivering a compiler that in no way uses the gtk libraries. Only the application, lazarus, BUILT with what we distribute uses the gtk libraries. So even putting them in the pp/bin/win32 directory doesn't solve the problem of distributing a binary of lazarus or any program built with it, when the time comes.

The ideal way is for the dlls to have incremental filenames

They do. If you look at the dlls you will see they are labeled

gtk-1.3.dll
gdk-1.3.dll
etc.

This alone takes care of some of your concerns. In most cases it shouldn't even matter having the gtk stuff installed in the /windows/system directory but I intend on putting the option in there for the user so if they really don't want to they can put it someplace else or not install them at all if they already have them.

DLL Hell isnt quite that simple, but it would help. If the user runs the older application and then launches lazarus, theres a chance the old dlls will still be in memory. At that point Lazarus will not run properly. We have this problem all the time with our winblows application. The way we get around it is instead of putting any dlls in the path, we keep our dlls exclusively in application directory with the .exe. The application's "start in" parameter is set to the same directory, so no path changes are neccesary. In the worst case, a clean reboot allows our application to load.

Putting the dlls into the "path" may not necessarly fix the problem, because the search order for dlls is something like this (but more complicated, obviously :)

Current Directory (or Start-In Directory), /windows/system, /windows, path

So i'm not sure we can come up with a solution that works for everyone immediately, but having a specifcation for where to install the dlls is a start atleast. :-)

The ideal way is for the dlls to have incremental filenames, (or a lazarus specific set of gtk dlls) but that's something the gtk group would have to do, and we would have to build lazarus for a particular release of gtk.

I never completely understood how unix handled this -- are there shared dynamic libraries in unix, and how do they version control them? Just curious.

== Ron

d0hb0y wrote

I never completely understood how unix handled this -- are there shared dynamic libraries in unix, and how do they version control them? Just curious.

They have the version number appended to their name. Simple.

Michael.

you wrote

3. It places all required DLLs into the appropriate Windows System directory.

This might not be the best idea. If a developer is using the gtk dll's for another purpose (maybe using gimp or gtk with other bindings) they may already have the dll's in /win/system and replacing them may cause problems. I remember a couple of months ago the dll's were ahead of the fpc bindings and it was very difficult to get copies of the old dll's for fpc development. I would bet the the dll's will be updated again and there will be a lag with the fpc bindings. If they're inadvertantly replaced in /win/system it will cause problems. I suggest putting the dll's in /pp/bin/win32 which will be on the path anyway and avoid incompatible dll problems in the future.

Not a bad idea. I'll adjust the next version so that the user has a choice of where they want to install the dlls.

you wrote

3. It places all required DLLs into the appropriate Windows System directory.

This might not be the best idea. If a developer is using the gtk dll's for another purpose (maybe using gimp or gtk with other bindings) they may already have the dll's in /win/system and replacing them may cause problems. I remember a couple of months ago the dll's were ahead of the fpc bindings and it was very difficult to get copies of the old dll's for fpc development. I would bet the the dll's will be updated again and there will be a lag with the fpc bindings. If they're inadvertantly replaced in /win/system it will cause problems. I suggest putting the dll's in /pp/bin/win32 which will be on the path anyway and avoid incompatible dll problems in the future.

If these were like the normal DLLs that plague Windows I would say yes but if you notice the libs follow the same practice that they do in Linux and the DLL name HAS a version number. So all of the DLLs are named like gtk-1.3.dll etc. These are the official 1.3 release of the DLLs. They shouldn't be overwriting anything. :-)

Hey what is the general opinion? Should I continue to have them placed in \windows\system or should they be in \pp\bin\win32?