From owner-freebsd-small Sat Jan 30 00:52:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA02977 for freebsd-small-outgoing; Sat, 30 Jan 1999 00:52:13 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA02972 for ; Sat, 30 Jan 1999 00:52:10 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 106W8P-0006jI-00; Sat, 30 Jan 1999 01:52:09 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id BAA75275 for ; Sat, 30 Jan 1999 01:52:22 -0700 (MST) Message-Id: <199901300852.BAA75275@harmony.village.org> To: small@FreeBSD.ORG Subject: compressed executables in low memory environements Date: Sat, 30 Jan 1999 01:52:22 -0700 From: Warner Losh Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has any thought (or work) been given to being able to run compressed executables basically in place? Right now the gzip device in FreeBSD does almost this, but requires the entire program to be decompressed before running. What I had in mind would be something that would use fixed length blocks (not optimal for compression, but not bad either) so that they could be "paged" into uncompress memory easily? by way of example: If we had a compression scheme that gave 2:1 compression (including headers), then we could "page in" 256 bytes of compressed program text decompressing it to 512 bytes of text that the CPU could understand and execute. This would allow one to run in tight memory spots and squeeze out extra use from the machine. If the entire image were resident in ram/rom, this could be a big win. The wins become bigger as the compression ratio improves. However, there are lots of problems going down this path. Do you have a tool that compresses the executables so they still have reasonable headers for the OS, or does the OS do this behind everybody's back. I know that WinCE 2.0 and newer uses techniques like this to live in such a limited footprint. Just curious. My need for something like this is still far in the future, as there are many preliminaries to be done before I get to the state of needing this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message