unofficial LaunchELF v4.42

[E P]

----- re: Debugged ps2-packer for Windows
That would be great. I've had a look at it myself, but my scant Linux experience and even lesser porting experience leaves me wondering both where and how to begin the adaptions. It's something I ought to learn eventually anyway, but doing so for this project would delay its results intolerably, I think.

I'll see what I can come up with especially since I would really like to have a ps2-packer for Windows with the fix.

----- re: Portable Linux setup
Sounds nice. I've plenty of extra flash drives and have been thinking about dedicating one of them to a portable Linux setup, but I'm probably not the best man to make such a setup. Any chance of sharing yours ?

Sure, I keep my custom profile separate, but I think if you setup the normal Slax on a flash drive all you would really need from me is the following modules to add to the modules directory of your flash drive in /slax/modules/ directory:

ps2-uLE_BUP.lzm: contains previously downloaded source setups for uLE along with ps2sdk-ports pieces for OPL.
ps2toolchain.lzm: contains the PS2 toolchain already prepared only without the ps2sdk built.
ps2tools.lzm: contains fsclient, ps2client, RadHostClient, ps2-packer, ps2-unpacker, and sjuncrunch Then there's what I've adapted for Unix; variants of your pack_ELF, unpack_ELF, uncrunch_ELF, and my own runELF that calls ps2client and executes the selected ELF while running PS2Link on the PS2.

Then you would also need a modified .bash_profile in the root directory that contains the user environment variables too.

If you don't want to post it on public servers I could give you an account on my private FTP server (running on my old Win2Ksrv PC).
I do have a 100Mbps connection nowdays, so it wouldn't be any major load on my bandwidth.
(And you might find some goodies to DL as well... )
Though in such case I guess we'd better switch this part of the discussion to PM.

I think it's only around a little more than 50MB's of extra stuff but it would be easier for you if you first got acclimated with the basic system in general. Slax unfortunately has become pretty stagnant as of late so I wouldn't plan on it working very well with any machine made in the last couple of years. Back when it was updated routinely all I would have to do is update the base setup and that was pretty much it. The process of updating was simply a matter of overwriting the existing files on the flash drive with those that I extracted from the downloaded ISO with winRAR.

So when you think you're ready to tackle it, I'll put together the stuff and point out what will likely be required at your end.

And more importantly, it gives no problems at all when run under the special environment of Cygwin's bash.
That worried me the most before my testing, as that environment is intended only for applications made for Cygwin.

Glad to know that so there's no need to isolate it from Cygwin. I saw when Slik subversion installed it automatically added itself to the Windows env path.

Yes, and the way it's now handled by setup.sh it should remain functional no matter what libs may get moved to github in future.
I'm not sure if such a move would change the revision numbers though. That depends on whether or not they can and will adopt a repository exactly as-is.

Other libraries revision numbers would likely change since I don't believe there is much control of how the server handles the bulk of the source changes. In our own case though we are pretty much using the most current revisions. The only exceptions being EEUG's SMS network modules and the ps2ftpd modules.

Oh and before I forget we may have to do something with that change that we had to made to the ps2sdk. It could cause problems with any future SMB implementation. I know it does with OPL at least the last time I mistakenly compiled in the change to iomanX.

[dlanor]

I'll see what I can come up with especially since I would really like to have a ps2-packer for Windows with the fix.

It would be best of course, though I'm not sure if any of our releases were affected by the bug. As I understood the posts on it, that bug only strikes for very specific elf sizes, and if uLE never hit such a precise size then it never was affected.

Sure, I keep my custom profile separate, but I think if you setup the normal Slax on a flash drive all you would really need from me is the following modules to add to the modules directory of your flash drive in /slax/modules/ directory:

OK, I'll look into it.

ps2-uLE_BUP.lzm: contains previously downloaded source setups for uLE along with ps2sdk-ports pieces for OPL.
ps2toolchain.lzm: contains the PS2 toolchain already prepared only without the ps2sdk built.
ps2tools.lzm: contains fsclient, ps2client, RadHostClient, ps2-packer, ps2-unpacker, and sjuncrunch Then there's what I've adapted for Unix; variants of your pack_ELF, unpack_ELF, uncrunch_ELF, and my own runELF that calls ps2client and executes the selected ELF while running PS2Link on the PS2.

Nice. I always prefer drag-drop where no complex arguments are needed, so I'll probably add some more too.

Then you would also need a modified .bash_profile in the root directory that contains the user environment variables too.

Sure, but I prefer to mess as little as possible with that, instead keeping project specifics in project specific scripts.

I think it's only around a little more than 50MB's of extra stuff but it would be easier for you if you first got acclimated with the basic system in general.

Ok, will do.

Slax unfortunately has become pretty stagnant as of late so I wouldn't plan on it working very well with any machine made in the last couple of years.

Thats unfortunate indeed. Though it will work with my current PCs it seems doomed for the new one I plan to get, which will naturally become my new main PC. And it must only be a matter of time for you too... (considering how this world of PCs evolves, at ever quickening pace)

Perhaps you should start looking for some other well portable Linux distro to take its place.
(Though I guess you may have been looking for that for some time already.)

Back when it was updated routinely all I would have to do is update the base setup and that was pretty much it. The process of updating was simply a matter of overwriting the existing files on the flash drive with those that I extracted from the downloaded ISO with winRAR.

Sure sounds easy enough...

So when you think you're ready to tackle it, I'll put together the stuff and point out what will likely be required at your end.

I will, but in preparation for that I'll just go ahead and create an account for you on my FTP server, and send you the login data for it in an email.
Is the old wiu.edu address as used back in 2008 still valid ? Or is there another that I should now use ? (PM the new address if needed.)
I've changed my own ISP since then, and the address you used for me then was for the server of my old ISP, so that one's history...
I'll send you my new email addresses in a PM.

Glad to know that so there's no need to isolate it from Cygwin. I saw when Slik subversion installed it automatically added itself to the Windows env path.

Yes, but since Cygwin's bash adds the Cygwin paths in front of the string from the Windows PATH variable, we still have to add the Slik path in front of it all, as done in the newest setup.sh script.

Other libraries revision numbers would likely change since I don't believe there is much control of how the server handles the bulk of the source changes.

Yeah, that's what I thought too. So if we do need an older lib for something we'll have to double-check what version to specify in github access.

Oh and before I forget we may have to do something with that change that we had to made to the ps2sdk. It could cause problems with any future SMB implementation. I know it does with OPL at least the last time I mistakenly compiled in the change to iomanX.

I'll keep that in mind if/when I make time for new attempts with the SMB stuff.

Best regards: dlanor

[E P]

It would be best of course, though I'm not sure if any of our releases were affected by the bug. As I understood the posts on it, that bug only strikes for very specific elf sizes, and if uLE never hit such a precise size then it never was affected.

Okay that's good to know. I vaguely remember the conversation before but I went ahead and added the change to my Linux setup.

Nice. I always prefer drag-drop where no complex arguments are needed, so I'll probably add some more too.

Yeah, drag and drop is how it currently works although it doesn't have the same feel as Windows.

Sure, but I prefer to mess as little as possible with that, instead keeping project specifics in project specific scripts.

The bash profile stuff is just a global set of environment variables so you can compile and run the scripts without having to declare everything in each individual script. I can just give you mine as there isn't really much to it. I forgot to mention that subversion as well along with its two dependencies are also required so it will be slightly more than 50MB's.

Thats unfortunate indeed. Though it will work with my current PCs it seems doomed for the new one I plan to get, which will naturally become my new main PC. And it must only be a matter of time for you too... (considering how this world of PCs evolves, at ever quickening pace)

My main machines are almost 10 years old and I can see how even web-browsers like firefox are requiring more and more from them all the time. My plan was to build a new machine once again but it gets harder and harder to start over. With only 2 years left of XP SP3 updates, the likelihood for upgrades is coming for a whole lot of people that have waited.

Perhaps you should start looking for some other well portable Linux distro to take its place.
(Though I guess you may have been looking for that for some time already.)

A lot of the users of Slax have already started with another project called porteus. It was produced by the same group of developers that made an offshoot version of Slax called Slax remix. While Slax remix was used to pacify the curiosity of users that wanted more from Slax, porteus became it's own entity and is now regularly updated unlike Slax. Porteus comes in two versions one for 32-bit and one for 64-bit. At the time I used porteus, I had no choice but to use the 32-bit version since I didn't have any hardware capable of running the 64-bit version. In my testing of the 32-bit version, I noticed some performance loss but that is becoming more typical of older hardware. All in all I liked that it started much faster and it wasn't as bloated as I had originally feared. Sure I do have plans to put the 64-bit version to the test but I still have to finish fighting with Windows 7 first.

Is the old wiu.edu address as used back in 2008 still valid ? Or is there another that I should now use ? (PM the new address if needed.)
I've changed my own ISP since then, and the address you used for me then was for the server of my old ISP, so that one's history...
I'll send you my new email addresses in a PM.

Old address is still good. Thanks for your new addresses.

All that's needed to setup to use Slax off a flash drive:
1. Download ISO from slax.org
2. Extract the ISO with winRAR to the root of the flash drive.
3. There should be two folders on the flash drive boot and slax. Go to the boot directory and run bootinst.bat to make the flash drive bootable.

If the BIOS supports booting flash drives, then you should see the Sylinux bootloader with the Slax background image. I always use the "Slax Always Fresh" option so it doesn't save anything. What I usually do is edit the slax.cfg file to remove all the instances of "changes=/slax/" because I don't want any unnecessary writes to the flash drive. The system runs entirely in memory so nothing is saved that way unless specified so it's somewhat like a live CD. Hard drives are mounted and accessible from the /mnt/ directory.

[dlanor]

The bash profile stuff is just a global set of environment variables so you can compile and run the scripts without having to declare everything in each individual script. I can just give you mine as there isn't really much to it. I forgot to mention that subversion as well along with its two dependencies are also required so it will be slightly more than 50MB's.

That's not a problem, and it's not much compared to what some of the modern applications consume.

My main machines are almost 10 years old and I can see how even web-browsers like firefox are requiring more and more from them all the time. My plan was to build a new machine once again but it gets harder and harder to start over. With only 2 years left of XP SP3 updates, the likelihood for upgrades is coming for a whole lot of people that have waited.

True, though I'm still running a Win2Ksrv system, several years after its support period expired.
But that's a pure server system, constantly running the same server software. It wouldn't be advisable for a main PC, running a variety of new software.

A lot of the users of Slax have already started with another project called porteus. It was produced by the same group of developers that made an offshoot version of Slax called Slax remix. While Slax remix was used to pacify the curiosity of users that wanted more from Slax, porteus became it's own entity and is now regularly updated unlike Slax. Porteus comes in two versions one for 32-bit and one for 64-bit. At the time I used porteus, I had no choice but to use the 32-bit version since I didn't have any hardware capable of running the 64-bit version. In my testing of the 32-bit version, I noticed some performance loss but that is becoming more typical of older hardware.

I'm still in the same boat on that, as I haven't got any 64-bit PC as yet. My next one will be such, of course, and will probably use Win7pro.
In any case, it sounds like that porteus project is worth trying out, as an alternative to slax.

I did check out the slax project a little, but it's probably not a good idea to now start using an OS which hasn't been updated or even tweaked in over two and a half years. (Its last system folder modifications were made in August 2009.)

All in all I liked that it started much faster and it wasn't as bloated as I had originally feared. Sure I do have plans to put the 64-bit version to the test but I still have to finish fighting with Windows 7 first.

I haven't even started on the Win7 stuff yet, but a friend of mine has tested it for a long time now, running it on a secondary PC for eight months in parallel to his main PC, for evaluation. And just a few days ago he decided to take the final step in making Win7 his main PC OS. So whenever I take that step I'll probably enlist his help for it and adopt most of his solutions to the problems involved.

But I strongly suspect that I'll then have to give up on the Cygwin PS2Dev setups, as it's highly doubtful if any compatible Cygwin setup will work under Win7.

Old address is still good. Thanks for your new addresses.

Fine, then I'll send you an email with the FTP login data.

All that's needed to setup to use Slax off a flash drive:
1. Download ISO from slax.org
2. Extract the ISO with winRAR to the root of the flash drive.
3. There should be two folders on the flash drive boot and slax. Go to the boot directory and run bootinst.bat to make the flash drive bootable.

I did that, but I also tested the OS as booted from a CD.

If the BIOS supports booting flash drives, then you should see the Sylinux bootloader with the Slax background image. I always use the "Slax Always Fresh" option so it doesn't save anything.

I was a bit confused by those choices, especially as related to the CD usage.

The site docs did state that system changes etc could be saved even when booting from a CD, obviously saving them somewhere on the system HDDs then, but the same docs never stated WHERE the saved data would be placed, not even hinting at how the HDD to be used would be chosen, and I was never offered the option of selecting it myself. So the end result is that it would save stuff somewhere with the user not having any clue as to where...

I did boot from CD that way, and did copy a file of my own into the /system folder, and I still have no idea where on my HDDs that storage took place...

What I usually do is edit the slax.cfg file to remove all the instances of "changes=/slax/" because I don't want any unnecessary writes to the flash drive.

That sounds like a good idea, but a less good idea was that the site docs never mentioned the existence of any "slax.cfg" file, nor how it might be edited to affect system performance. Maybe I'm being picky here, but it's that kind of thing that makes Linux systems unpopular with many people.

Some Linux 'Gurus' are too fond of keeping important details to themselves, or taking for granted that 'everyone already knows that bit', which is absurd when trying to introduce users to a new OS that they've never used before.

The system runs entirely in memory so nothing is saved that way unless specified so it's somewhat like a live CD. Hard drives are mounted and accessible from the /mnt/ directory.

I had no trouble finding my HDDs and accessing them, though I wasn't too fond of the file manager's window handling.

I wasn't able to modify window positioning persistently (the first was always opened at top left screen corner), nor the file display mode (defaulted to big fat icons for every new window opened). But possibly I missed some alternate configuration method in my short test runs.

Best regards: dlanor

[E P]

I'm still in the same boat on that, as I haven't got any 64-bit PC as yet. My next one will be such, of course, and will probably use Win7pro.
In any case, it sounds like that porteus project is worth trying out, as an alternative to slax.

I had a rough and tumble battle getting Slax to work on one laptop last year whereas another one from 2010 worked quite alright. It's hard to abandon something that works so well for most things today but the future is coming fast.

I did check out the slax project a little, but it's probably not a good idea to now start using an OS which hasn't been updated or even tweaked in over two and a half years. (Its last system folder modifications were made in August 2009.)

I agree that's why I laid out that bit of info upfront. Unfortunately as I may have stated in the past, porteus uses a much different setup depending on whether you use 64-bit vs 32-bit. You get KDE 4 with 64-bit and KDE 3.5 with the 32-bit. It's likely a problem because KDE 4 is to KDE 3.5 as Vista/7 was to XP. Many diehard users that prefer KDE 3.5 have a lot is disgust for KDE 4 so you can see why I stuck with what I have for the moment. It's bad enough managing all the Windows machines and all the programs.

I haven't even started on the Win7 stuff yet, but a friend of mine has tested it for a long time now, running it on a secondary PC for eight months in parallel to his main PC, for evaluation. And just a few days ago he decided to take the final step in making Win7 his main PC OS. So whenever I take that step I'll probably enlist his help for it and adopt most of his solutions to the problems involved.

I have Windows 7 installed on a laptop but once I made a dual boot setup with XP Pro I kind of neglected the Windows 7 part. It's really awkward using the OS with UAC. I've also seen my share of virus infections on friends and family members machines. So the whole "it's safer" is just not true. Although I still place most of the blame on silly OEM's like Dell that put so much additional software on their machines that it amounts to more security holes for bad guys to exploit. People don't have any clue anymore what they have on their machines.

But I strongly suspect that I'll then have to give up on the Cygwin PS2Dev setups, as it's highly doubtful if any compatible Cygwin setup will work under Win7.

That's what I believe but I haven't tested it yet. I do have Windows 7 Pro, which allows for XP mode, but I still haven't tinkered with it.

Fine, then I'll send you an email with the FTP login data.

Thanks, I got it. I'll wait and make sure I add in a few configuration changes to slax so Konqueror, the filemanager, is a little more friendly.

I was a bit confused by those choices, especially as related to the CD usage.

The site docs did state that system changes etc could be saved even when booting from a CD, obviously saving them somewhere on the system HDDs then, but the same docs never stated WHERE the saved data would be placed, not even hinting at how the HDD to be used would be chosen, and I was never offered the option of selecting it myself. So the end result is that it would save stuff somewhere with the user not having any clue as to where...

I did boot from CD that way, and did copy a file of my own into the /system folder, and I still have no idea where on my HDDs that storage took place...

Slax had a lot of info in the old forums, which were replaced with the inferior one that you have likely have seen by now. I learned a ton of stuff in regards to Linux fonts, networking, printers, and getting hardware acceleration working with OpenGL. Those old forums are long since gone as of 2007. The author of Slax wanted something easier for him to maintain and ultimately disposed of what obviously worked so well. All this did was scare away contributors that really knew their stuff and provided tutorials for just about everything a Windows user such as myself could possibly want to know. I have seen that porteus' website is going back to the old way Slax once did with forum subsections so users can produce documentation to their hearts content. Too bad it's to early to tell if it will be as successful.

The only things that should get saved are those that are copied directly to the mounted drives. Slax is running entirely in memory so whatever is saved outside the mounted drives will be lost on restart or shutdown of the computer. The files with the .lzm extension are modules that are loaded on startup. The modules contain files and directories that will be uncompacted within your system memory and placed within the Slax filesystem. The beauty of this is you can 'activate' and 'deactive' the modules from the Slax Modules manager to free up resources. The module manager is in System -> Slax Module Manager.

That sounds like a good idea, but a less good idea was that the site docs never mentioned the existence of any "slax.cfg" file, nor how it might be edited to affect system performance. Maybe I'm being picky here, but it's that kind of thing that makes Linux systems unpopular with many people.

Yeah, Linux isn't for everyone. The fun for me came from tweaking it into a more comfortable setup but it isn't something that can't be figured out in short order sadly.

Some Linux 'Gurus' are too fond of keeping important details to themselves, or taking for granted that 'everyone already knows that bit', which is absurd when trying to introduce users to a new OS that they've never used before.

A major issue is that they don't even use the same thing when it comes to desktop environments: gnome, KDE, xfce, lxde, etc. It becomes a nightmare to use applications that were met to run only in certain environments. I have had to build a lot of my own stuff that I never would have touched in Windows. I've even made GUI's with Kommander scripts for applications I use frequently.

I wasn't able to modify window positioning persistently (the first was always opened at top left screen corner), nor the file display mode (defaulted to big fat icons for every new window opened). But possibly I missed some alternate configuration method in my short test runs.

Konqueror can be a bit of a pain to setup as it saves its settings quite differently. It retains its settings by going to Settings -> Save View Profile "File Management". Yes, it's strange. I'll provide my Konqueror settings so that it resembles Windows Explorer somewhat.

I will be sure to give you a set of step by step instructions on how I build uLE so you can see what it entails once I thoroughly vet it on my own system.

[averybomb1]

hey um in 4.42b is the mass facor finally fixed. I kinda got annoyed when i plug both usbs in ulaunch elf 4.42a, it always says mass, and i have to press x/O to go into it, then come back out and mass1 is loaded

[dlanor]

hey um in 4.42b is the mass facor finally fixed.

'facor' ???

I kinda got annoyed when i plug both usbs in ulaunch elf 4.42a, it always says mass, and i have to press x/O to go into it, then come back out and mass1 is loaded

I don't think you understand how the FileManager and uLE in general works, when you complain of this.

The PS2 has several CPU units, the main one being the 'EE' and the secondary one being the 'IOP' which has two roles. In PS1 mode it acts as the original PS1 CPU and in PS2 mode it acts as a slave CPU to handle I/O processing (hence its acronym IOP). That IOP processor has its own RAM memory space of only 2 MB, which is very small space considering that this is where all PS2 device drivers have their main data buffers, cache areas, as well as all device driver code.

This means that loading all device drivers at startup of uLE would use up a whole lot of IOP RAM, and lead to trouble when that RAM runs out, which it often would do then, if not while still in uLE itself then as soon as it attempts to launch an application which also needs IOP RAM (possibly using it without first clearing any old drivers). And the whole problem is further complicated by the fact that some device drivers are so 'persistent' that a newly started application that does NOT want an already loaded driver, may yet be unable to unload it in order to free up some needed IOP RAM for other use.

To minimize such problems uLE has been coded to avoid unnecessary loading of device drivers that are not currently needed, such need being defined both by user actions and by the original launch conditions. In addition to the minimal drivers loaded at boot, uLE will also load device drivers as made necessary by user actions in the current session. Thus trying to browse "host:" will load network drivers, and trying to browse "mass:" will load USB drivers (also done if you try to launch a shortcut leading to a USB drive).

The problem here is that it's only after first loading the USBHDFSD driver that it can tell uLE how many USB partitions it has detected, so it's only after this driver load (and consumption of IOP RAM), that it becomes possible to know if displaying "mass1:" in the FileManager device list would be useful.

The only real alternative to this method would be to always have entries for all the possible USB partitions, meaning that we'd always have 10 massX: names cluttering up the listing, with most of them not being accessible of course. That would simply be too messy, so we've settled for the current method where the initial browsing into mass: loads the driver, which then tells us what additional USB partitions are available beyond "mass0:" (== "mass:").

I'm open to suggestions for improved methods of doing this, but any such method MUST retain the characteristic of not wasting a single byte of IOP RAM for USB usage except when user actions require real USB access. That's one of the 'core' ideas in the uLE design, to make it as compatible as possible to other homebrews.

Best regards: dlanor

[dlanor]

@E P:
I just want to confirm that I've read your latest post, though I don't have much to say in reply at this time.

I've started to dig into the uLE sources again, with a view to adding to the experimental SMB stuff in it, but it's slow going after so long a time of not working with PS2 code...

Still, on a positive note the little SMB code already in there (the SMB logon menu in "MISC/Debug Info") still works identically in v4.42b as it did in v4.42a, so the new libs have not affected these parts at all. All three different logon methods still work well with my two WinXP computers, and with my Win2Kserver only the two passworded logon methods work (it won't accept any anonymous logon). And these are exactly the same results as before, when using the old libs.

Best regards: dlanor

[E P]

@E P:
I just want to confirm that I've read your latest post, though I don't have much to say in reply at this time.

No problem. I've been busy with other things. I did incorporate a few changes to the settings into a module for Slax that I use frequently. No need to get to concerned with the Slax stuff especially since I haven't yet put together a basic tutorial on how to use it for building and testing uLE.

Still, on a positive note the little SMB code already in there (the SMB logon menu in "MISC/Debug Info") still works identically in v4.42b as it did in v4.42a, so the new libs have not affected these parts at all. All three different logon methods still work well with my two WinXP computers, and with my Win2Kserver only the two passworded logon methods work (it won't accept any anonymous logon). And these are exactly the same results as before, when using the old libs.

That's good to know as that was the one thing I did not test. Although I did use the SMB test login a few times quite a while back when your preliminary SMB stuff was first introduced.

[acaN]

Just in case it may be helpful, i've tested smb in debug menu too, and logon worked ok with my 70008 ps2 and winxp.