Thank you for testing - very nice feedback!
I did have a quick test of xaw3dxft - tested linking with chimera - works OK.
I will try to make a build package with my xawplus variant of xwoaf.
xwoaf - rebuild
For keyboard you will have to modify the build - and for ethernet you need to build the kernel and correct module for your net device - and then rebuild the image. A lot of work without guarantee for success - but also a lot of fun while doing itfoxpup wrote:Thanks Keef!
Works very well. xwaof boots very fast on my P3 (amd palomino). It's faster than anything
I put it on ext3, next to several frugal puppies. So it does not have to be ext2.
However 2 issues for now:
my keyboard is azerty (be-latin1)
I have no internet, normally it is a network connection, ethernet, eth0
How can I set up these?
Where can I find this kind of info, or even what is or is not possible?
It bothered me to release xwoaf-toolchain without the ability to rebuild the old kernel-2.2.25. It needs gcc-2.95.3 or older - every test to patch kernel source to accept gcc-3.x.x have failed. And cross compiling gcc-2.95.3 to work in the toolchain also failed. But:
One can build a simple gcc-2.95.3 within the toolchain using gcc-3.4.3, install it in /opt and then use it to compile the kernel. Only minor patch to the kernel needed to cope with binutils-2.19.1.
It is important to link cc to the gcc-2.95.3 compiler before doing the kernel build - it is linked to ccache in the toolchain.
Ran into problems with missing as86 and ld86 - not every version of it builds with uclibc to a working bin - but bin86-0.4 does.
So in the end I am now able to compile the original xwoaf kernel-2.2.25 and modules to same size and features as the original.
I have updated the howto here where also xwoaf-build-package_kernel.tar.gz can be downloaded (buildscripts, patches and sources).
So the adventurous can now time travel back and build kernel 2.2.25 (bl3, xwoaf and skatos are some of the more known distributions that used it or nearby relatives).
One can build a simple gcc-2.95.3 within the toolchain using gcc-3.4.3, install it in /opt and then use it to compile the kernel. Only minor patch to the kernel needed to cope with binutils-2.19.1.
It is important to link cc to the gcc-2.95.3 compiler before doing the kernel build - it is linked to ccache in the toolchain.
Ran into problems with missing as86 and ld86 - not every version of it builds with uclibc to a working bin - but bin86-0.4 does.
So in the end I am now able to compile the original xwoaf kernel-2.2.25 and modules to same size and features as the original.
I have updated the howto here where also xwoaf-build-package_kernel.tar.gz can be downloaded (buildscripts, patches and sources).
So the adventurous can now time travel back and build kernel 2.2.25 (bl3, xwoaf and skatos are some of the more known distributions that used it or nearby relatives).
Tbh I would love to see what software can still be compiled with gtk1.2 and if there are older versions of some software of which we cannot compile that would still suit our needs.BarryK wrote:Yes, I see so many interesting projects, that have been forgot or lost, bits and pieces that could be put together to build a new kind of radically small, lean-and-mean Puppy.
A new pup built with xlib apps, tinyx, and gtk 1.2, would be great. There were such nice gtk1.2 apps that we abandoned. Also there were some very interesting projects, such as xft support in gtk1.2, for antialiased fonts -- there was a git site for that.
I feel like Puppy has really changed a lot since even the 4.x days. From the loss of Tcl, to the splintering into dozens of different puppies. I like the variety, but at the same time, it seems like it adds a lot of possible incompatibility, back in the day you didn't have to worry about what the base distro was and what arch the package needed to be in
If you wanted a program you would just hit up the forum and people would show their wares, almost like a little informal marketplace, which I will admit I always liked
NeroVance: Agree! One option to address the possible incompatibility of pets for various versions of Puppy could be to supply static linked binaries. This give "portability" beyond Puppy as well. I know this is not possible with some applications, but when possible, it could be the target. Size on disc will increase but that is really not a limiting factor for most users...
Some findings working further with xwoaf...
My first approach to get more room was to use "mklibs" which repack the dynamic libraries to only contain what the applications on the floppy needs - and that does work.
Then tried to use upx on the binaries but that gave a slight increase in total size (of Image.gz).
sstrip reduces a tiny bit but not with the magnitude I was looking for.
exepak works - but upx seems more efficient.
The dynamic libraries wont compress with upx - though recent versions of upx works with libc libraries - it refuses to compress uclibc dynamic libraries.
upx can compress the kernel but afterwards kernel wont boot.
Never compress busybox as execution speed decreases a lot.
My present solution is to create multi call binaries and static link them. This give the possibility to reduce size of dynamic libraries left and the static linked binaries compress well with upx.
The creation of multi call binaries is a much more complicated process but frees space. And they work outside xwoaf too as no external libraries are needed.
The new free space is used to include cdrom and loop modules in kernel (you cant compress modules but build in modules are compressed with the kernel), upgraded version of busybox and added support for creating/formating partitions and added extlinux to make hard disk boot able. So now install to hard disk can be performed - at least from floppy - install from iso-boot depend if the cd/dvd-drive is recognized correctly by this 15 year old kernel. And tools for setting the keyboard is now included.
At the moment the floppy contains the following applications: jwm menu rxvt xcmd xinit xsetroot xcalc xcalendar xe xfilemanager xminesweep busybox pr extlinux Xvesa.
xwoaf_rebuild3 floppy-image
xwoaf_rebuild3 iso-image
Some findings working further with xwoaf...
My first approach to get more room was to use "mklibs" which repack the dynamic libraries to only contain what the applications on the floppy needs - and that does work.
Then tried to use upx on the binaries but that gave a slight increase in total size (of Image.gz).
sstrip reduces a tiny bit but not with the magnitude I was looking for.
exepak works - but upx seems more efficient.
The dynamic libraries wont compress with upx - though recent versions of upx works with libc libraries - it refuses to compress uclibc dynamic libraries.
upx can compress the kernel but afterwards kernel wont boot.
Never compress busybox as execution speed decreases a lot.
My present solution is to create multi call binaries and static link them. This give the possibility to reduce size of dynamic libraries left and the static linked binaries compress well with upx.
The creation of multi call binaries is a much more complicated process but frees space. And they work outside xwoaf too as no external libraries are needed.
The new free space is used to include cdrom and loop modules in kernel (you cant compress modules but build in modules are compressed with the kernel), upgraded version of busybox and added support for creating/formating partitions and added extlinux to make hard disk boot able. So now install to hard disk can be performed - at least from floppy - install from iso-boot depend if the cd/dvd-drive is recognized correctly by this 15 year old kernel. And tools for setting the keyboard is now included.
At the moment the floppy contains the following applications: jwm menu rxvt xcmd xinit xsetroot xcalc xcalendar xe xfilemanager xminesweep busybox pr extlinux Xvesa.
xwoaf_rebuild3 floppy-image
xwoaf_rebuild3 iso-image
-
technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I came to the same conclusions regarding upx on a compressed squashfs as well as inside an initramfs contained within a compressed kernel.goingnuts wrote:...
Then tried to use upx on the binaries but that gave a slight increase in total size (of Image.gz).
sstrip reduces a tiny bit but not with the magnitude I was looking for.
exepak works - but upx seems more efficient.
The dynamic libraries wont compress with upx - though recent versions of upx works with libc libraries - it refuses to compress uclibc dynamic libraries.
upx can compress the kernel but afterwards kernel wont boot.
Never compress busybox as execution speed decreases a lot.
My present solution is to create multi call binaries and static link them. This give the possibility to reduce size of dynamic libraries left and the static linked binaries compress well with upx.
The creation of multi call binaries is a much more complicated process but frees space. And they work outside xwoaf too as no external libraries are needed.
The new free space is used to include cdrom and loop modules in kernel (you cant compress modules but build in modules are compressed with the kernel), upgraded version of busybox and added support for creating/formating partitions and added extlinux to make hard disk boot able. So now install to hard disk can be performed - at least from floppy - install from iso-boot depend if the cd/dvd-drive is recognized correctly by this 15 year old kernel. And tools for setting the keyboard is now included.
At the moment the floppy contains the following applications: jwm menu rxvt xcmd xinit xsetroot xcalc xcalendar xe xfilemanager xminesweep busybox pr extlinux Xvesa.
xwoaf_rebuild3 floppy-image
xwoaf_rebuild3 iso-image
I'd be willing to start/contribute-to a github project for a basic X-app mcb. Xvesa/fbdev + jwm + a terminal(st?). I could even make it work as a submodule of toybox if thats what people prefer. I have the start of a basic C library that could be incorporated into the project so that the C library is not an issue. I also have a patch for jwm that significantly reduces RAM usage (uses nanosvg and stb-image instead of cairo, jpeg and png ... also adds support for gif, bmp, photoshop and other images) With black background running Xvesa, jwm and rxvt, I had it under 4Mb (~3.7Mb IIRC). The background actually used more resources than all 3 of those apps combined with my screen resolution (4MB).
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
technosaurus: Thank you for the feedback. For me the mcb process is a collection of sources, patches and build scripts - if that is what you are suggesting I would like to contribute. If its a rewrite of source code - I do not think I can contribute much. I am not quite sure how licenses should be handled when creating mcbs - any thought on that subject?
There might be a synergy between a floppy distribution and a basic initramfs for larger sized distribution: Both could target GUI environment and basic system applications/tools.
I find XawPlus based applications small enough to fit in floppy size but they lack keyboard handling (as far as I can tell) - that is a major drawback if you only have keyboard to navigate with. If you or others know ways to configure Athena widgets to be controlled by keyboard only, I am very interested in a how-to-do-it.
There might be a synergy between a floppy distribution and a basic initramfs for larger sized distribution: Both could target GUI environment and basic system applications/tools.
I find XawPlus based applications small enough to fit in floppy size but they lack keyboard handling (as far as I can tell) - that is a major drawback if you only have keyboard to navigate with. If you or others know ways to configure Athena widgets to be controlled by keyboard only, I am very interested in a how-to-do-it.
Don't know if this is useful. http://xawm.sourceforge.net/
The XawM Widget set is based on the widely-distributed Xaw3d widget set. XawM makes a few changes required to give Athena the "modern" look-and-feel. It borrows a few features from neXtaw and other widgets sets as required to obtain a modern look and feel, although the actual source code is entirely based on Xaw3d.
Of special interest is the addition of keyboard traversal. I may also add pixmap handling because some modern applications like to have color images, and because it will help encourage people to port to it.
No attempt will be made to add new functionality to the existing widget set. This library is intended to be compatible with the Athena widget set.
Thanks Keef! It should add the keyboard navigation - the functions are there. A first try did not work - but you gave me something to follow.
Update: It actually works - sort of: Navigation with Tab and activation with Spacebar is OK but mouse clicks are ignored - despite setting focusPolicy in .Xdefaults. Another issue is lack of focus when application starts - focus seems to be set by mouse pointer...
Update: It actually works - sort of: Navigation with Tab and activation with Spacebar is OK but mouse clicks are ignored - despite setting focusPolicy in .Xdefaults. Another issue is lack of focus when application starts - focus seems to be set by mouse pointer...
Attached a patch to jwm-0.23 which add features from later versions:
* scale icons in menu
* do not show sticky windows in pager
* shade/unshade window with mouse button 4 & 5
* change desktop with with mouse button 4 & 5
* restack windows
* move/resize windows with Alt+mouse button 1 & 3
* adds -restart function
without major increase in size of compiled binary.
Motivation was to get desklaunch running in xwoaf - it needs the ability to move generated (sticky) icons with Alt+mouse button 1. Random number of icons was drawn when running desklaunch - the restack helped on that. And all icons showed up in pager - not pretty
.
My xlibs multicall binary has been expanded with desklaunch so now holds static linked bins of: desklaunch-1.1.7 jwm-0.23 menu-3.00 rxvt-2.6.4 xcmd-1.05 xinit-1.0.1 and xsetroot-1.5.
The mcb is 133K.
Attached also image of xwoaf-version running with the above.
* scale icons in menu
* do not show sticky windows in pager
* shade/unshade window with mouse button 4 & 5
* change desktop with with mouse button 4 & 5
* restack windows
* move/resize windows with Alt+mouse button 1 & 3
* adds -restart function
without major increase in size of compiled binary.
Motivation was to get desklaunch running in xwoaf - it needs the ability to move generated (sticky) icons with Alt+mouse button 1. Random number of icons was drawn when running desklaunch - the restack helped on that. And all icons showed up in pager - not pretty
.My xlibs multicall binary has been expanded with desklaunch so now holds static linked bins of: desklaunch-1.1.7 jwm-0.23 menu-3.00 rxvt-2.6.4 xcmd-1.05 xinit-1.0.1 and xsetroot-1.5.
The mcb is 133K.
Attached also image of xwoaf-version running with the above.
- Attachments
-
- snap0004.png
- (55.93 KiB) Downloaded 531 times
-
- jwm-0.23_various.diff.gz
- fake gz-extension
- (10.25 KiB) Downloaded 184 times
-
BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I have created chrootable MUSL filesystems from Alpine Linux packages, for x86_64, x86 and armhf, see my blog post:
http://barryk.org/news/?viewDetailed=00524
Now, the temptation to use the x86 MUSL rootfs in xwoaf, became overwhelming. So, gave it a go.
Download the x86 rootfs from here (67MB):
http://distro.ibiblio.org/quirky/alpine ... x86.tar.gz
It expands to folder 'alpine-rootfs-x86'.
Copy script 'chroot-x86' out of it, and use that instead of xwoaf's 'xwoaf-dev.sh' to chroot into alpine-rootfs-x86.
Expand 'xwoaf-build-package.tar.gz' inside alpine-rootfs-x86, then "cd src". Instead of running "./xwoaf_build", I did "cd recipes" and ran "./tinyxlib-0.01.sh"
...success!!!
However, the next one, "./tinyxserver-0.03.sh" has hit a hurdle:
...now what?
EDIT:
Ah, asm/mtrr.h is in the linux-headers package. As the Alpine rootfs has the 'apk' package manager installed, and has Internet access from within the chroot, I *should" be able to install that.
http://barryk.org/news/?viewDetailed=00524
Now, the temptation to use the x86 MUSL rootfs in xwoaf, became overwhelming. So, gave it a go.
Download the x86 rootfs from here (67MB):
http://distro.ibiblio.org/quirky/alpine ... x86.tar.gz
It expands to folder 'alpine-rootfs-x86'.
Copy script 'chroot-x86' out of it, and use that instead of xwoaf's 'xwoaf-dev.sh' to chroot into alpine-rootfs-x86.
Expand 'xwoaf-build-package.tar.gz' inside alpine-rootfs-x86, then "cd src". Instead of running "./xwoaf_build", I did "cd recipes" and ran "./tinyxlib-0.01.sh"
...success!!!
However, the next one, "./tinyxserver-0.03.sh" has hit a hurdle:
Code: Select all
kmap.c:38:22: fatal error: asm/mtrr.h: No such file or directory
#include <asm/mtrr.h>EDIT:
Ah, asm/mtrr.h is in the linux-headers package. As the Alpine rootfs has the 'apk' package manager installed, and has Internet access from within the chroot, I *should" be able to install that.
[url]https://bkhome.org/news/[/url]
-
BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Continuing from previous post. Having chrooted into 'alpine-rootfs-x86', if there is Internet access, then /etc/resolve.conf also got copied in, so have Internet access inside the rootfs.
So, did this:
Of course, xwoaf is using an older kernel. Never mind that for now.
compiling tinyxserver now gets to:
EDIT:
Ah ha, zlib dev files are missing, so did this:
Ha ha, not there yet:
Fascinating hey! I have to leave it for now, have other things to do today.
EDIT2:
A quick note before I depart though. the 'linux-headers' that I installed has /usr/include/asm/vm86.h.
goingnuts,
What do you reckon, would that asm/vm86.h be ok?
Of course, this is kernel 4.4.x. But, I am interested in compiling xwoaf with recent kernel, not concerned about that fitting-in-a-floppy requirement.
So, did this:
Code: Select all
puppypc21513:/src/recipe# apk add linux-headers
(1/1) Installing linux-headers (4.4.6-r1)
OK: 196 MiB in 74 packagescompiling tinyxserver now gets to:
Code: Select all
/usr/bin/gcc -DNOERROR -Wl,--gc-sections,--sort-common,-s -o Xfbdev dix/libdix.a os/libos.a hw/kdrive/fbdev/libfbdev.a miext/layer/liblayer.a hw/kdrive/libkdrive.a hw/kdrive/linux/liblinux.a miext/shadow/libshadow.a fb/libfb.a mi/libmi.a Xext/libext.a Xext/extmod/libextmod.a XTrap/libxtrap.a randr/librandr.a render/librender.a record/librecord.a -L/usr/lib /usr/lib/libXfont.a -lXext -lX11 -lXdmcp -lz -lm
/usr/lib/gcc/i586-alpine-linux-musl/6.2.1/../../../../i586-alpine-linux-musl/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
make: *** [Makefile:33: Xfbdev] Error 1Ah ha, zlib dev files are missing, so did this:
Code: Select all
puppypc21513:/src/recipe# apk add zlib-dev
(1/1) Installing zlib-dev (1.2.8-r2)
OK: 196 MiB in 75 packagesCode: Select all
make[1]: Entering directory '/src/build/tinyxserver-0.03/hw/kdrive/vesa'
/usr/bin/gcc -I../../../include -I../../../mi -I../../../miext/layer -I../../../fb -I../../../render -I../.. -pipe -fPIC -Os -Wall -D_BSD_SOURCE -D_GNU_SOURCE -D__KERNEL_STRICT_NAMES -fno-strength-reduce -nodefaultlibs -fno-strict-aliasing -ffunction-sections -fdata-sections -I. -I/usr/include -DNOERROR -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE -DTOSHIBA_SMM -D_SVID_SOURCE -D_GNU_SOURCE -DX_LOCALE -DKDRIVESERVER -DGCCUSESGAS -DDDXOSINIT -DNOFONTSERVERACCESS -DNDEBUG -DNARROWPROTO -DPIXPRIV -DFUNCPROTO=15 -DCOMPILEDDEFAULTFONTPATH=\"/usr/X11R6/lib/X11/fonts/misc/\" -DRGB_DB=\"/usr/X11R6/lib/X11/rgb\" -D_POSIX_C_SOURCE=2 -DUSE_RGB_TXT -D__KERNEL_STRICT_NAMES -c -o vga.o vga.c
In file included from vesa.h:29:0,
from vga.c:25:
vm86.h:54:22: fatal error: sys/vm86.h: No such file or directory
#include <sys/vm86.h>EDIT2:
A quick note before I depart though. the 'linux-headers' that I installed has /usr/include/asm/vm86.h.
goingnuts,
What do you reckon, would that asm/vm86.h be ok?
Of course, this is kernel 4.4.x. But, I am interested in compiling xwoaf with recent kernel, not concerned about that fitting-in-a-floppy requirement.
[url]https://bkhome.org/news/[/url]
-
BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
goingnuts sent me a pm, to work that iguleder and ibidem did with tinysxerver and musl:
http://murga-linux.com/puppy/posting.ph ... fbae980a7c
...had a brief glance, see mention of that asm/vm86.h
Anyway, I have scratched this particular itch. My Alpine rootfs could be used for the xwoaf build, but will need more work.
Also, it will need the proper kernel headers for the kernel that xwoaf is using.
http://murga-linux.com/puppy/posting.ph ... fbae980a7c
...had a brief glance, see mention of that asm/vm86.h
Anyway, I have scratched this particular itch. My Alpine rootfs could be used for the xwoaf build, but will need more work.
Also, it will need the proper kernel headers for the kernel that xwoaf is using.
[url]https://bkhome.org/news/[/url]
Xwoaf-rebuild-4.0 now available - view first post for link to download and small description or visit for details. Most linux GUI applications on a floppy - ever.
- Attachments
-
- xwoaf-rebuild4.png
- (42.93 KiB) Downloaded 268 times
goingnuts wrote:Xwoaf-rebuild-4.0 now available - view first post for link to download and small description or visit for details. Most linux GUI applications on a floppy - ever.
Hi goingnuts,
I just downloaded the "4" iso, and loaded her up. She booted great, straight to the desktop, after choosing my keyboard layout (30)
But then I ran into a problem. No matter what I tried, wired and/or wireless, or even booting on a different machine ( a laptop & trying its touchpad), I cannot get a functioning mouse. I've tried USB mouses, wireless mouses, even the old style PS/2 wired mouse on an old Compaq machine. No mouse-type was recognized despite booting up great everywhere.This just seems incredible what you've done.....just wish I could get one of my darn mouse(s) to work to keep going forward with it
belham2: Thank you for your feedback! Most chance for success if you boot images in qemu as modules included in kernel are targeted qemu.
Mouse support is PS/2-type and works on real hardware here including a laptop. I have recompiled kernel with additional support for Logitech busmouse and Microsoft busmouse. If you want to give it another trial the iso can be downloaded here.
Mouse support is PS/2-type and works on real hardware here including a laptop. I have recompiled kernel with additional support for Logitech busmouse and Microsoft busmouse. If you want to give it another trial the iso can be downloaded here.
- Attachments
-
- bzImage.gz
- woaf-light kernel - fake .gz
- (225.28 KiB) Downloaded 23 times