linux music tools It is quite possible and was done all the time in the bad

Janina Sajka janina at
Tue Jul 28 21:32:16 UTC 2015

OK, I understand about overlays and about swapping and accessing from
RAM. But, isn't that more than just compiling for a different OS?
Doesn't that require reconsidering how the code actually fits together
and executes? Surely you don't want to swap on each instruction.

My reaction was to the suggestion to compile Lilypond for DOS. Why is
beyond me, given how accessible Lilypond already is on the Linux

The only enhancement that we don't have supported is that which comes
from an intelligent front end that helps you with the artifacts of
writing the .ly file. These are usually on screen wysiwyg scores not of
much help to a blind composer/arranger.

Whoever pointed to the emacs lilypond mode probably pointed to the best
combo, imo, for the blind user. However, it is quite possible to do the
job with vim, ed, or even nano.

So where's the benefit of trying to take Lilypond to DOS. I don't see
it, even if it were just a recompile with a modern compiler.


martin McCormick writes:
> old days of severely limited system resources that we all had
> back in the eighties and early nineties or in 2015 if one is a
> glutton for punishment.
> 	It was called overlaying and a smart programmer could
> write an executable file which was built to come apart like a
> piece of large furniture such that there was probably part of the
> program in memory all the time plus one or more sub-parts which
> were sucked in to memory while the application was doing
> particular things and then another piece would be pulled in when
> something else needed to be done and so forth.
> 	The program could have been huge and there was
> theoretically only one limit and that was fitting the whole
> bundle on to the disks used for installation and or the hard
> drive.
> 	I used to write 8086 code on a Microsoft assembler when I
> was learning how to crash P.C's scientifically in the eighties
> and I remember there were instructions in the manuals for how to
> write overlays. I never got that sophisticated but real
> programmers did write exactly the kind of code being discussed
> here and that's how applications that could not fit in to your
> memory did, well, sort of.
> 	Nowadays, there is not nearly as much need to do that
> sort of thing when writing applications but the idea of virtual
> memory makes it happen automatically.
> 	If you use the "free" command on a unix system, it will
> tell you that you have X amount of memory. That's your RAM.
> That's the golden memory, the fast stuff that makes your system
> really scream along.
> 	When you now pull in a big bunch of data, the operating
> system puts as much as it can safely afford to do in an area of
> RAM and, if there are still too many data elements, it uses swap
> space on your hard drive that you hopefully have setup for
> just this eventuality. This is not nearly as fast as your RAM,
> but it beats crashing the program or you whole system and
> programmers who write applications do not have to worry about
> overlays and which parts of the executable are accessible at what
> times nearly as much as they used to do.
> Martin
> Shlomi Fish <shlomif at> wrote
> > Hi Janina and everybody,
> > 
> > On Sat, 25 Jul 2015 16:00:12 -0400
> > Janina Sajka <janina at> wrote:
> > 
> > > Are you serious? The Lilypond executable alone is 4.5 megs. How's that
> > > supposed to even run within the 640K confines of DOS? Let alone the
> > > required libraries to compile the binary?
> > >
> > 
> > I recall that DJGPP (see )?s 
> > executables
> > could access more RAM than that using
> > (DPMI). So it 
> > may be
> > possible.
> _______________________________________________
> Blinux-list mailing list
> Blinux-list at


Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina at
		Email:	janina at

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats

More information about the Blinux-list mailing list