[Freedos-user] Jemm v5.68 available
Hello, Jemm v5.68 is now available at http://www.japheth.de/Jemm.html changelog for 5.68: - bugfix: JLOAD's Lock DMA function ignored flag to check for 64 kB border crossing. - NMIs occuring inside the monitor are now silently routed to v86-mode. Previous Jemm versions displayed an exception dump. - XDMA32 added, supports legacy and native IDE controllers. - XCDROM32 now supports legacy and native IDE controllers. - some bugfixes in XCDROM32. Many thanks to my fiend Jack R. Ellis! Without him and his XDMA/XCDROM drivers this update would not have been possible. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Updater
On 12/2/07, Aitor Santamaría [EMAIL PROTECTED] wrote: Hello, 2007/12/2, Jim Hall [EMAIL PROTECTED]: There is an important difference. What I put in the general archive on ibiblio is a mirror of other people's work. For most programs, they already have another primary location, and (license permitting) I'm just putting it on ibiblio so that it has at least a 2nd place to live (for example, in case the original site goes down or otherwise becomes unavailable.) Users should still be able to download the original program in its original archive from ibiblio, AND IT SHOULD BE IDENTICAL TO WHAT WAS ORIGINALLY RELEASED BY THE AUTHOR/MAINTAINER. But it is not even true for the packages in the distributions, compared to the ones created by us (for which I'm grateful, they are better!). Just to be clear: what I am trying to say is that files put in http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/ should be assumed to be pkgs, not the originally zip file release of the program. And we should consider changing the names of these pkgs so they have a FDP or PKG extension. But files that are in any other directory on ibiblio (like say http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ or http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/ should assumed to be a mirror of the author's original zip file release. I don't want to re-zip or re-package any files that are in the mirror areas. I consider that to be inappropriate, as it confuses users to what was the actual original released file. But I think it's presumed to be ok to re-package programs for inclusion in a distribution (to be sure they have the correct dir structure, etc) so that is why I mak Perhaps it could be a good idea that besides any ZIP (untouched) there would be a file with the same name, but some extension, like LSM or another, that would contain all those extra info needed for the packager: the version or date to compare, the mapping of files onto the pkg structure, and other useful info (such as post-install script that I mentioned too). Actually, this info file could be the XML that Jim suggested, a quite extensible idea (hopefully XMLs are easy to read in C?). If the zip file contains an LSM file, I usually unzip it next to the original zip file ... just for this reason, so users would know what was contained in the file, and to make things easier on the person creating a pkg. Mateusz I just had a brief off-list discussion where I suggested we may want to change how FDPKG manages packages. One thing we may want to do is have all pkg files have a PKG or FDP (FreeDOS Package) extension, rather than keep the zip extension, even though the pkg file is just a zip file with a particular directory structure. Changing the extension would be a good way to implicitly declare that the pkg file is not the original release zip file (4dos759.zip 4dos759.fdp, for example.) Oops, I hadn't read this when I wrote my previous mail. Needless to say, I like the idea ;-) It might be a good/interesting idea, though, to add an option to FDUPDATE to tell it to read/unzip the packages in-place (i.e. assume a local repo) rather than wget them to a local cache. Obviously, that works well when the repo is local, but not so well when the repo is on a web server somewhere. You're talking (I guess?) as some type of repository type, that could be either internet or local. Perhaps the address could give the clue: http://www.freedos.org/ file://d:\updates Nice solution, I like that. -jh - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Updater
On 12/2/07, Aitor Santamaría [EMAIL PROTECTED] wrote: [...] Following the idea I exposed before, you could even have locally a folder called: C:\FREEDOS\3RDPARTY\... where it would unpackage all that is not packaged on the new structure (in the words before, being a ZIP and not a FPF). Hmm... not sure I like that idea. If it's in the distribution, it should be in a package. And I don't think the installer or FDPKG should try to do this either - these should just report the file is not in pkg format and not install it (there's no pkg install tracking, etc) - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Updater
On 12/2/07, Aitor Santamaría [EMAIL PROTECTED] wrote: As I see it, the fact that some DOS software is mirrored at ibiblio's FreeDOS repository is a privilege, not a nice present. Thus, it could be an idea that there is some kind of FreeDOS logotype test (LOL ;-)) meaning that some programs have passed the minimum requirements of: [...] See my other email. The mirror areas of ibiblio should remain mirror areas, and not a FreeDOS logo test. Besides, I had made arrangements with some authors (and still do) to host their primary release zip file on ibiblio because they did not have a web page to host it. In these cases, it already breaks the suggestion that placement on ibiblio is a privilege. But programs that are in the distributions can be assumed to be re-zipped pkgs, especially so if we choose to rename them with FDP or PKG. I thought of the second because the programmer could encode in that LSM the condition to run certain Post-Install script, that would be run after the package is installed. The extended LSM could host other information, that we might not exploit at this moment, but maybe in the future. Things like: dependencies, path to executable, path to a HTML-Help file (for automatic Help update), etc. Then there's the decission whether the FreeDOS package would be able to deal with these special FPF files (and deal with the versioning stuff, post-install script, maybe dependencies), and for standard ZIP packages, well, just the basic (there exists XXX.ZIP with date YYY, newer than current XXX.LSM, install?). Interestingly, at one point on FDPM we had considered adding dependencies and post-install tasks a-la the RPM spec (%dependencies% and %pre% and %post% sections after the End in the LSM.) But we never followed up on it while I worked on FDPM. 3. We may (at some later date) choose to change the FreeDOS pkg directory layout. As of today, no suggestions to do this have been made, but a year from now it's possible that we may want to change it. I don't want to re-zip everything on ibiblio to meet the new pkg standard. Perhaps it is the moment to see if the pkg structure needs a review or not. We could discuss about it, and settle certain FreeDOS directory structure 1.0, so that programs are based on it. A clever idea that Microsoft does (for example, to allow locale in filenames, C:\Program Files is, in my system, C:\Archivos de Programa\) IIRC is to use a kind of location variable, so that for example, %10 would be Program Files, %11 would be Windows folder, etc. It would be certainly quite a lot of more work, but it could be that the ZIP (or FPF) does NOT have directories, but has instead a mapping file: \DISKCOPY.001 = %12\DISKCOPY.EXE (and in turn, %12 could be standarised to C:\FREEDOS\BIN by the packager program). If we're open to discussing the pkg format, I'd like to suggest 3 things: 1. adherence to the directory layout (already defined, but probably not well known) 2. move the LSM file out of the zip file archive, and into the zip file comment header. This makes it easier for programs built using zip file tools to easily read the LSM header without having to unzip part of the archive just to read a single APPINFO/__.LSM file. 3. adherence to the LSM file format. We have a lot of LSMs out there now that don't follow the LSM format very well. We should either move back to what the LSM spec actually says, or agree that we're abandoning it and choose some other file format for pkg info. -jh - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Updater
Hi Jim, Interestingly, at one point on FDPM we had considered adding dependencies and post-install tasks a-la the RPM spec (%dependencies% and %pre% and %post% sections after the End in the LSM.) But we never followed up on it while I worked on FDPM. The current implementation (by Blair) is that FDPKG looks for certain filenames in the zipped package. Those fixed-name files can describe: Things to do for updates (as a batch file, can for example delete the old EXE if the new version uses a COM), things for postinstall (batch), things for uninstall (batch afair) and dependencies (machine readable text file). \DISKCOPY.001 = %12\DISKCOPY.EXE (and in turn, %12 could be standarised to C:\FREEDOS\BIN by the packager program). I think that would be overdoing things. We should be happy if we get more downloads available in the fine existing fdpkg zip format for now :-). 2. move the LSM file out of the zip file archive, and into the zip file comment header. This makes it easier for programs built using zip file tools to easily read the LSM header without having to unzip part of the archive just to read a single APPINFO/__.LSM file. Is the comment header really easier to unzip than a file? I had the impression that zip libraries like for example the one used in htmlhelp focus on unzipping files to files or buffers anyway. I agree to 1. and 3. - we should stick to the existing and proven directory structure and LSM file format :-). Yet it would be okay to extend LSM, for example to have 2 fields for URLs, one for a general project page and one for the exact file download of the fdpkg (!) zip of this version. Eric :-) - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How to make a FreeDOS bootable CD
Hi Marc, VFD (Virtual Floppy Driver) is a good, non-Vista, method of editing floppy disk images. It mounts the image file as a lettered floppy drive and you can copy files, do drag and drop, or whatever. Executing the SYS command is the only challenge - you pretty much need a pre-made floppy disk image to get the boot sector. Try ImDisk Virtual Disk Driver instead of VFD. It is much more bugfree than VFD and even installs itself as a context menu item. I do not know if it is already Vista compatible but this project is still actively being developed. Regards Norbert. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How to make a FreeDOS bootable CD
Sorry, I forgot the link for ImDisk: http://www.ltr-data.se/opencode.html - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] PloP Bootmanager
Hi all, even if not open source, but a new version of PloP Bootmanager was released. It is free for personal and corporate use. It also adds the ability to boot from usb-sticks even if the bios doesn't support usb boot devices. download: http://www.plop.at/en/bootmanagerdl.html Regards Norbert. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Jemm v5.68 available
On 12/3/07, Japheth [EMAIL PROTECTED] wrote: Hello, Jemm v5.68 is now available at http://www.japheth.de/Jemm.html [...] Very cool. I've added a news item for this (will show up in about an hour) and updated the LSM. I also mirrored your zip files on ibiblio. -jh - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Gui for FreeDOS
Oscar sent me the latest WinDos. I gave it a quick look, and everything looks ok to me. At least, I didn't see anything that looked like it was lifted from non-GPL sources (for example, several icons were instantly recognizable from GNOME, but that's under the GNU GPL as well, so that's ok.) But I can't run the GUI - I get a resolution not supported error under DOSEMU, regardless of what resolution I try to set in regedit. Anyway, I posted his archive on ibiblio at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/gui/windos/ It would be great if others here could try it out and see if it works for them. -jh - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Gui for FreeDOS
Hi.. Ok. lo que voy a hacer es instalar linux en mi pc y voy a ejecutar WinDos desde DosEmu-FreeDOS y tratare de solucionar lo mas rapido posible el problema. thanks again. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Updater
Hello, 2007/12/3, Jim Hall [EMAIL PROTECTED]: On 12/2/07, Aitor Santamaría [EMAIL PROTECTED] wrote: But programs that are in the distributions can be assumed to be re-zipped pkgs, especially so if we choose to rename them with FDP or PKG. That is good. Then you could go along with an standard. Perhaps re-versioning the packing howto. Reviewing other things, as the must of including the LSM file somewhere (as in the header), and the possible extensions to the LSM (see below). Interestingly, at one point on FDPM we had considered adding dependencies and post-install tasks a-la the RPM spec (%dependencies% and %pre% and %post% sections after the End in the LSM.) But we never followed up on it while I worked on FDPM. What I am then a bit lost is, what and where is the use of the XML file that was mentioned in other parts of the conversation? If we're open to discussing the pkg format, I'd like to suggest 3 things: 1. adherence to the directory layout (already defined, but probably not well known) 2. move the LSM file out of the zip file archive, and into the zip file comment header. This makes it easier for programs built using zip file tools to easily read the LSM header without having to unzip part of the archive just to read a single APPINFO/__.LSM file. 3. adherence to the LSM file format. We have a lot of LSMs out there now that don't follow the LSM format very well. We should either move back to what the LSM spec actually says, or agree that we're abandoning it and choose some other file format for pkg info. The (2) idea is great, specially if it can be extracted using a C API too! As for the rest, I would simply re-version the how-to that talks about packing (the contribution howto?). Aitor - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Gui for FreeDOS - dosemu mini review
Hi Jim, But I can't run the GUI - I get a resolution not supported error under DOSEMU, regardless of what resolution I try to set in regedit. It would be good if Windos displays which resolution it WANTS. Or if it automatically selects something. Default is 640x480x16, but I found that my dosemu only offers 32 bit per pixel modes. When I select the obvious 640x480x32, windos crashes. When I select 800x600x32, it does start and show an empty desktop with a pic of a mouse as background. With 1024x768x32, it does start up first but then exits at once. It says VBE 3.0 not available. I think VBE 2.0 should be enough! And I think it actually MEANS that there is not enough framebuffer RAM available for 1024x768x32 VBE 2.0 mode ;-). VBE 3.0 adds a protected mode interface and refresh rate control, but I have written DJGPP programs which use VBE 2.0 without problem. I just enter the mode, get a handle for the framebuffer memory, and do not need the BIOS after that anyway. When I edit my .dosemurc to say $_X_vgaemu_memsize = (8192) then windos does start up at first but then crashes, traceback EIP: 0x000603db 0x0011f8f2. With 800x600, Windos also crashes often, and I cannot get to a menu even if it does not crash. When I try to use a depth 8 mode (256 color mode) I get a crash with traceback EIP 0x000d15d2 only. Modes with depth 15 also crash after WinDos shows the start screen. No idea why DOSEMU 1.4 only gives DOS 15 and 32 bit depth modes but no 16 and 24 bit depth modes. Translation of Regedit: Enter open F4 Edit F7 New F8 Delete? F9 File? Basically you use the cursor keys and Enter until the right key is highlighted and then type F4. Then type a value and hit enter. When all keys are set, hit esc to exit and save the new settings. Problem with Regedit: It is NOT available in the installed system. It is only in the directory with the installer files. This should be changed, such files should be put into some tool directory. The source code is installed too - it should be put in a separate directory and you should have the option to not install it. The full install with source code is 5000 files and 160 MB, plus the 145 plus 28 MB that you need during install! The few exe files which are left in the install dir instead of in the windos dir are mostly apps for running inside windos. Exception is regedit and of course install. I believe that the files are MEANT to be in the WinDos directory after install, but that they end up in the wrong directory because I selected another directory, not c:/windos, as install target directory...? When you run install, you have to type tab and then enter to accept the GPL. Actually the GPL is not meant to be as a you have to accept before you install this license! Of course it is nice to show the GPL but you do not have to accept it. Next, you hit enter to open a menu for principal (main) and select windos. Hit enter. Use the cursor to select extras, hit enter, and see that there are no choices apart from nada (nothing) ;-). Hit tab and enter to go to the next page. Edit the target path (just type, use backspace to remove the path which is suggested as default). Use tab to go to the next field, edit that, use tab twice to go to the siguiente pagina, hit enter, and enjoy how piles of files are extracted from a big uncompressed .bar archive file. I think the installer will be more happy if you enable your long file name drivers first before you install Windos, but it seems to work with short file names, too. I think environ bat is not adjusted to match the actual install directory if you select something else than c:/windos ... The registry.wd file contains the registry as editable text but windos.reg is binary. Interestingly, system32 does not contain a bin directory, but djgpp.env looks as if it should. As far as I can tell, WinDos opens the following files before it crashes: debug.txt djgpp.env (as pointed to by %DJGPP% env var), WinDos.reg and the soundblaster. It seems to be impossible to run WinDos without sound output...?? Most of what you get when you install WinDos is the source code of everything and many DJGPP compile tools. The actual WinDos seems to be pretty small: - tmp, extra (empty) - a few files (ca 2 mb) - desktop/desktop.dat (4 kb) drivers.dos/mouse/ctmouse... (5 kb) - scrsaver (8+12 kb) cursors (14 files of 766 bytes each) - bitmaps (ca 1/2 mb, could be 200k less if using PCX for WinDos.bmp) - bmp (ca 1 mb, almost the only place which contains long file names, some of which are broken down to name~1.png style while some other names are correctly installed as long. Note that windos uses some library which can render PNGs :-)) [more LFN: info/allegro.info LIB/GCC-LIB/DJGPP/3.04/INCLUDE/syslimits.h LIB/GCC-LIB/DJGPP/3.04/libstdcxx.a LIB/libstdcxx.a system32/doc/rhide/rhide.html I think WinDos can easily be all SFN...] - bmps (ca 1 mb, includes a picture of the author, why not as JPG? :-)) Things which are probably not needed to run
