Activity for Shidel
-
Shidel posted a comment on ticket #401
Why did you open bug report 402 instead of replying to 401? Please do not open a new bug report each time you want to comment or send a message. I already know about the ZIP that is included in ARACHNE. However, I have not looked at it to verify it is 8086 compatible and contains sources. If you read my reply, this is one of the "possible alternatives" to which I was referring. Out of projects I am responsible (Online Repositories, FreeDOS translations, Release Media Builder, and others) and numerous...
-
This is not an unknown issue and has not yet been resolved. See, the https://sourceforge.net/p/freedos/mailman/message/59222415/ thread. It discusses the problems with the current UNZIP which requires 386+CWSDPMI and possible alternatives. Those have not been fully investigated as of yet. A satisfactory solution will require a opensource UNZIP that does can run on a 8086 and will not automatically use a SWAP file on 386+ hardware.
-
At present, FDIMPLES has two different ways it displays the "File List". For packages that are installed but NOT available on the install Media, it displays the list of Files that were installed with their path information. These items get grouped into a "Installed!" group. The Second way is for packages that are available on the install Media. Regardless of whether or not they are installed, those show a simple list of contents of the zip file. This is not likely to change in the current Major version...
-
At present, FDIMPLES has two different ways it displays the "File List". For packages that are installed but NOT available on the install Media, it displays the list of Files that were installed with their path information. These items get grouped into a "Installed!" group. The Second way are for packages that are available on the install Media. Regardless of whether or not they are installed, the show a simple list of contents of the zip file. This is not likely to change in the current Major version...
-
Thank you
-
Patch to handle binary files correctly
-
Format Stack Overflow
-
I also posted this issue more recently on Github. Yes, this issue is now fixed as of FORMAT v0.92.
-
FreeDOS 1.1 test release #2 - Keyb crashes
-
FD1.1test2-2011JUL18_FDAUTO.BAT
-
FreeDOS rmdir failed
-
Not a bug, but a feature request satisfied by using DELTREE.
-
Critical "MungaBunga-BUG" in DELTREE
-
Actually, I think the user is referring to something else. For example, PC-DOS 7 was supplied on multiple 1.44MB floppy diskettes. The first diskette was using a standard format. It would boot the PC and load an XDF driver. The remainder of the floppy diskettes used for the install were not formatted normally. The used an alternate format to place more data on the 1.44mb diskette therefore reducing the total number of disks required to install the operating system. As a side note, those files were...
-
XCOPY changes the timestamp of some files
-
CTRL-C dos not work
-
If I understand correctly... The user would boot and exit the installer to run a program from a different diskette. I that is the case, the user can select "Exit to DOS" in FreeDOS 1.2 and later to accomplish the same task. So, this support issue was resolved a while ago.
-
A typo in BSPLASH.BAT makes it unusable to change splash scr
-
I performed a search of all current packages that are/will be provided on the next FreeDOS Interim Build (and eventually the next OS release). There is no BSPLASH.BAT file in those packages.
-
Classic Xwing game goes black and cuases reboot
-
Very old and inactive thread.
-
mKEYB 0.52 [Nov 19 2022] breaks entering | char with ALT GR + | keys on a German keyboard layout
-
FreeCom does not support %ERRORLEVEL%
-
extra memory devel
-
extra memory devel
-
extra memory devel
-
extra memory devel
-
Installation FD12 hangs; unable to locate ...
-
The installer for FreeDOS 1.2 & 1.3 are batch file based programs. To pass data around inside the installer and make calculations, it uses external command line utilities and I/O redirection. In earlier versions of the installer, there were a few places in the installer that would have problems if a key was pressed durring that processing. Later versions of those tools were updated to updated to prevent erroneous keystrokes from interfering with the install process.
-
“Polish” translated wrong in German version
-
fdisk 1.3.4 supports only 6 digits for size, you may need 7 at 2 TB HDs
-
fdisk 1.3.4 supports only 6 digits for size, you may need 7 at 2 TB HDs
-
FreeDOS help (hhstndrd) freezes on system with "set LANG=RU"
-
Strange character at boot
-
Help crashes after you have opened in about 15 - 25 sites
-
LABEL not printing return+line feed on exit.
-
Doszip Commander ver 2.55 (DZ.EXE) can't read floppy if floppy has no label or if floppy is empty
-
extra memory devel
-
extra memory devel
-
extra memory devel
-
Some documentation updates
-
Mouse Wheel Event Commands
-
General comment cleanup
-
Added ScrollWheel support to QCrt Unit and QScroll
-
As you noted, the FreePascal package is not "broken" it contains files require Long File Name support inside a LFNFILES.ZIP archve. This was also the case with the package provided with FreeDOS 1.3. This is also the case for any other package that contains LFN files. Some packages work fine without extracting the LFNFILES.ZIP. While others dont work. FDIMPLES does a great deal of complex data processing to generate a browsable package list of the installed, available and upgradable packages. It pulls...
-
While The Floppy Edition of FreeDOS does not use zip compression for several reasons, it could be useful to provide a 16-bit real mode unzip program in that version of the release. However, the CD and USB versions of FreeDOS do not need a 16-bit unzip program. First the CD/DVD drivers available to be provided with FreeDOS require a 386 or better computer. You will be hard pressed to find a 286 or lesser based machine that includes a CD-ROM drive. Furthermore, all zip files provided with FreeDOS on...
-
Hi Oliver, There is now a new tool called VTEST that is part of V8Power Tools. It supports 64-bit signed numerical and string comparisons as well as file system tests. Things like this are possible: vtest /tf %A /lt %B /gt %C /and %B /ne %D Which would evaluate as: /tf Display TRUE, FALSE or ERROR when finished. %A /lt %B is %A less than %B %B /gt %C is %B greater than %C /and End of First Expression, Evaluate next expression. %B /ne %D is %B not equal to %D TRUE if both the first and second parts...
-
Hi Oliver, There is now a new tool called VTEST that is part of V8Power Tools. It supports 64-bit signed numerical and string comparisons as well as file system tests. Things like this are possible: vtest /tf %A /lt %B /gt %C /and %B /ne %D Which would evaluate as: /tf Display TRUE, FALSE or ERROR when finished. %A /lt %B is %A less than %B %B /gt %C is %B greater than %C /and End of First Expression, Evaluate next expression. %B /ne %D is %B not equal to %D TRUE if both the first and second parts...
-
If you are using FreeDOS and do not need to stick to built-in shell commands, consider using VECHO. It is part of V8Power Tools and installed under FreeDOS 1.2 and later. V8Power Tools is what makes a a lot of magic happen. It is also what powers the user interface of FreeDOS Installer using batch files. VECHO is also what provides the colored text for the FreeDOS welcome message when booted. You can use it to do things like: vecho "Is %A% >= %B%?" Or, vecho Is %A% ">=" %B%? Or, add a little color...
-
If you are using FreeDOS and do not need to stick to built-in shell commands, consider using VECHO. It is part of V8Power Tools and installed under FreeDOS 1.2 and later. V8Power Tools is what makes a a lot of magic happen. It is also what powers the user interface of FreeDOS Installer using batch files. VECHO is also what provides the colored text for the FreeDOS welcome message when booted. You can use it to do things like: vecho "Is %A% >= %B%?" Or, vecho Is %A% ">=" %B%? Or, add a little color...
-
Improved mouse compatibility
-
Added a bug report at the project development repository for the it's maintianer. Github LABEL Issue #17 - File and directory collision bug
-
Can't format HDD
-
Thread is outdated. Closed. If problem still exists it can be reopened.
-
Also, Is this on BARE METAL or running in a virtual machine or other emulator (like DOSBOX)?
-
Sounds like Windows is not overwritting or updating the boot code in the Master Boot Record. You can try using a utility to wipe clean that information then reinstall windows afterwards. A good free utility that can perform such an operation is MBRTOOL.
-
Minor project Readme update
-
Thanks Willi, I updated the package for GitLab Archive Package and the Unstable Updates version. Also, I put a raw version for @jhall1 in the file mirrors on ibiblio.
-
Thenthe first thing I would do is update JEMM from v5.79 to v5.80 and see if it resolves the issue. If you have networking, you can use fdnpkg update jemm or head over to the Official Software Repository and download it. On a side note, you can download the latest version we have of the packages by visiting the Repository at https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/ and downloading the cdrom.iso. It is automatically created once a day when packages have been updated....
-
Willi is correct. Since it does't even run MS-DOS, I wouldn't call it a FreeDOS bug. However, There are some things you can try to see if you can get it working. Enable config stepping. make note of the program/driver etc where the freeze is occuring. Reboot again and skip that item. If all works well and you can live without that item, just rem it. If you need it, you may have to find an alternative. However, just because it freezes when a specific program/driver runs. It does not mean that it is...
-
The author pointed me to a page where the sources could be downloaded. So, I mirrored them to https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/games/fmines/ for you Jim. the sources zip includes backup files and graphics before and after conversion and is nearly 70MB uncompressed. So, I will trim it down some for inclusion in the package that goes on the release media.
-
I did some checking. Apparently, we have never had the sources. I don't know why that is the case. I just sent an email to the author regarding the missing sources for that game. Hopefully, he will send me a copy of the sources or at least a link for me to download them. Unfortunately, we may have to end up removing that game for lack of sources.
-
Problems with the CRYNWR.BAT file in fdos\drivers\crynwr\
-
The original issue was resolved. As for LSPPP, it was being installed to it's own directory. That had been changed to install it into the CRYNWR directory in 1.3 FINAL. So, it should be fixed. However, I have no means to perform a dialup connection and test wether or not it works.
-
Unable to install 'base/htmlhelp' package under VirtualBox (1.3RC4)
-
There was a filename collision in the SOURCES, it was resolved.
-
TR/FR NLS for BlockDrop & SaysWho
-
For now, I added it to the Development build. However, I cannot promise it will remain "live" on the LiveCD for FreeDOS 1.3 Final. My guess is it will probably be there.
-
When a issue reported through email is made visible to non-group members, the sender's email will be visible. Personally, I would prefer that was not the case. But like with sourceforge mailing lists, there is no setting to change that. However, if the sender of the email requests it not be made visible, it can be left flagged as confidential and only group members can see and respond to it. Honestly, todays spam filters a fairly good. My public email address is all over the internet visible to just...
-
There are numerious reasons we are moving the Bug Tacking to GitLab. It is already in use and the primary location for bug reports, feature requests and other issues. However, a user does not need to have or setup a GitLab account to submit those items. They can simply send an email to the account provided on the FreeDOS website Bug Page. Issues that are report through email are initially marked as confidential until reviewed and made visible to non-group members.
-
Double keypress workaround
-
NLS update
-
devel
-
NLS update
-
NLS update
-
devel
-
Sound Effects label using wrong component ID
-
Sound Effects label using wrong component ID
-
updated NLS
-
updated NLS
-
I removed those two directoies. Sounds good. For now, I just sent a "Guest" invite to https://gitlab.com/FreeDOS/devel/euphoria. When you become more familiar with using GitLab, I'll increase the permissions. :-) Generally, I can be contactedthe developer forum. You can sign up the on the FreeDOS website at Forums. Also, by email. My email is listed on the same page under the how to get a slack invite.
-
Hello Shian, I understand you are new to Git and similar versioning systems. So, I think your request to join the FD-NLS translation project on GitLab was possibly a mistake. You probably meant fot that to be in Euphoria. However, there a couple ways to handle updating those pacakge versions. One method, is to create a fork of the package to your GitLab account. Then, you can make any changes and experiment on that fork. Eventually, you would then issue a pull request to the original package. Another...
-
Your welcome. Thanks for the feedback. :-)
-
Last minute changes to the contents of the Bonus CD caused it to no longer be identified as a vaild package source. The issue was discovered shortly after the release of RC5 and FDIMPLES was updated to be able to identify the disc. You can download the latest version of FDIMPLES or just the binary from the GitLab FreeDOS Archive.
-
Looked good to me. A lot shorter now. ;-)
-
Well, all we need to do is either delete the file from the GitLab Repo or rename/move the file to the ROOT of that project. The RBE builds packages using the GitLab Repo. Also, files in the topmost directory for a project are not included in the packages. Those files are mostly notes and for individuals looking at the repo for the project. Just give the word and I'll change it. Or, if your feeling adventurous you could do it Jim. :-)
-
Or possibly, you're browser is saying -- Oh I have that in my cache, so here ya go... Giving you an old copy.
-
For verification, I downloaded the DEV0 build from 1/4/22 620pm. It contains the correct version of CRYNWR.BAT. It can be easily Identifed by looking at the first REM statement which either contains [T[4,X]] or the old [T[4|X]] (which caused the "X]]" command not found error) So my guess is one of two things, you unknowingly have switched the CD being mounted by Virtual Box to a earlier, buggier version. If you are keeping multiple DEV0 copies and restore an older snapshot, it will change the disc...
-
For verification, I donloaded the DEV0 build from 1/4/22 620pm. It contains the correct version of CRYNWR.BAT. It can be easily Identifed by looking at the first REM statement which either contains [T[4,X]] or the old [T[4|X]] (which caused the "X]]" command not found error) So my guess is one of two things, you unknowingly have switched the CD being mounted by Virtual Box to a earlier, buggier version. If you are keeping multiple DEV0 copies and restore an older snapshot, it will change the disc...
-
package:gnuchcp re-organization
-
moved terminus font to gnufonts package
-
Well, I just pushed another dev test build a few minutes ago at 2:30pm est (2nd one today). It all seems good now. Basically, there were 2 problems. First, the bad command should have always been showing. There is a rem statement with a pipe in it near the start. Personally, I feel it is a shell bug. But, MS-DOS 6.22 behaves the same so at least it is a consistent bug. Basically, it looks like this... C:\>rem I will not say anything | echo I lied I lied C:\> I feel anything after REM should be ignored....
-
There is now also a package for LSppp. However, it is installed to a different directory. Personally, I don't use CRYNWR. Would it be better for the LSppp package to install into the same directory as CRYNWR? I can easily change that.
-
The bug that was happening in VirtualBox is also happening in the real Laptop
-
Thank you for your report. Although it is not really a believed to be a bug but a compitibility issue. The problem was resolved in 1.3-RC1. The current version is now 1.3-RC4. However, later today or tomorrow RC5 will be made available with offical announcements made later this month. Your English translation was very good. Have you considered contributing translations to Japanese for the FreeDOS project? Although DOS cannot display actual Japanese characters in text mode, I thought there were longer...
-
Possibly good news. I think I may have found the issue. I was looking at the area of the installer that creates the new config files in hopes of seeing something that could be causing the issue. This lead my to discovering an additional minor bug in FreeCOM that was probably causing it. So, I made a small change to the installer that would compensate for that bug. I'm hopeful that it is resolved now. For more info on this specific shell bug that I think was resposible... see https://github.com/F...
-
Unfortunately, there is no logging support in it. Going forward, if we don't migrate to a diferent installer, I may add logging or additional functionality for debugging. 6.1.28 is fairly new. So, probably not an issue. As for the ancient hardware... It could possibly not be 386 compatible. The CD's and CD boot floppy all use the 386 kernel to boot. It could be you require the 8086 kernel instead. The FloppyEdition boots the 8086 kernel. However, at present it will always assume it is installing...
-
Yes, VirtualBox did not like booting a CD the way the LegacyCD boots. It's not a bug in the installer or tools. It came down to VM hardware implementation compatibility. The LiveCD boots using a more complx and completely different method. I don't know if the bug in VirtualBox still exists or not. But, generally everyone should use the LiveCD unless they really need to use the LegacyCD. There is only a very limited range of hardware that can boot from CD and not boot the LiveCD. At sme point, we...
-
Yes, VirtualBox did not like booting a CD the way the LegacyCD boots. It's not actually a bug in the installer or tools. It really cam down to VM hardware implementation compatibility. The LiveCD boots using a more complx and completely different method. I don't know if the bug in VirtualBox still exists or not. But, generally everyone should use the LiveCD unless they really need to use the LegacyCD. There is only a very limited range of hardware that can boot from CD and not boot the LiveCD. At...
-
Hi, the Freezing issue on the "Gathering Information" screen was being caused by an incompatibility with some systems. More or less there was a built in delay to prevent the screen from disappearing to quickly. The utility was using a high precision timer. Some systems and Virtual Machines would end up sitting forever wainting for a timer event that never occured. I don't recall if this fix made it into RC4 or not. However, it should no longer happen in RC5. Now the -- lets call it "hit enter" bug...
1 >
