Re: [Freedos-devel] FreeDOS JetDirect driver
On 7/18/2014 4:10 AM, Mateusz Viste wrote: Actually, that's exactly what jd.exe does from the wattcp/pprd package, too. Send job to printer or spooler using direct protocol. http://archives.scovetta.com/pub/simtelnet/msdos/lan/pprd200.zip Source code is included. The nice thing is that it uses printer configuration from wattcp.cfg, so it'a bit more 'integrated' than a general-purpose netcat. Mateusz This: nc -target 192.168.2.20 9100 -bin \xmas.ps is not simple enough? I much prefer to use general purpose tools when they are available. Netcat is a pretty standard Unix tool, and this is just one of the many tricks you can do with it. No configuration in a file needed either. Mike -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS JetDirect driver
On 7/17/2014 1:49 PM, Jim Michaels wrote: for the network stufff, I was thinking of opening a socket and just dumping the printer data from stdin or from a file depnding on commandline options. it' s the easiest way to go. sockets is probably about 10-20 lines of code I think. google sockets example (or look in the source code of the telnet program in wattcp). then it's not DHCP printers are another thing altogether. they do exist, they seem to be the consumer printers like officejets and like printers that have wifi or ethernet. they default to DHCP, but can be manually config'd for static (works better I think with static, just make sure ip is outside of DHCP range). not sure how to handle usb printers at this point. I know they are packet driven. usb.org has the specs. usb 2.0 uses 8b/10b but usb 3.0 uses 128b/132b encoding. You are aware that netcat already exists and has the capabilities that you wrote about - the ability to open a socket to the printer and send data from stdin or a file. (See my email to this list dated July 12th.) Mike -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeDOS Roadmap: (Was Getting started
Caution - long rant. Please be mindful about how you quote and comment so it doesn't turn into a jumbled mess The road map from the Wiki dated August 2010 seems to be wildly optimistic. It is talking about tightly integrated protected mode support, protected mode networking and USB, borrowing device driver code from other OSes, etc. I don't think that road map is feasible. Ever. Tightly integrated protected mode support basically leaves 8088 or 80286 class machines behind. Which seems fair given that those machines are 25 or more years old now but a big market for running any form of DOS is to support old hardware. So a new version of FreeDOS that does not work on that hardware limits its reach. (I suspect that those machines would be perfectly happy remaining frozen in time, running an earlier version of FreeDOS so this may not be a real issue for them.) Re: Protected mode USB. What does protected mode mean in this context - is the intent to run in protected mode all of the time, not just switch into protected mode when an application loads? I could see where protected mode device drivers for block storage and input devices would be very useful, but if they come and go as applications load and unload then that limits their utility. (Think of a DOS device driver for external storage on a USB drive ... would the drive letter be invisible at the DOS prompt because you are not in protected mode, and then be available to your application only if it runs in protected mode?) Re: Protected mode Networking. Every DOS application brings its own networking code. To take advantage of any new networking you would need to change the applications. The short story ... The DOS application ecosystem is pretty well frozen in time, about 20 years back. If you want to make an enhancement to FreeDOS generally usable by FreeDOS users then it has to pretty much work transparently with existing applications. Or start adding new applications. I don't think there is any point to adding new features to FreeDOS that older applications can not use. If you go down that path then you have to start modifying applications. Then you might as well decide on a new toolchain, other kernel upgrades that we need, etc. and then we are off on a new OS hobby project. We all know how successful those turn out. If we can add device drivers or code to the kernel that keep FreeDOS alive and well on modern hardware then we can keep enabling the applications that we already have. Even this might not be necessary; if hardware support becomes too much of a problem then falling back to emulation environments that run FreeDOS in a virtual machine might be the answer. (If you have a hard requirement that FreeDOS boots on bare hardware then this does not work for you.) We need users/developers/programmers ... I don't see the lack of advanced OS features as a threat to FreeDOS. I see adding them as the threat. Unless you are on older hardware Linux has everything you need, including a large developer base. There is no harm in providing a library that allows a new application to spin off a thread on an unused core, but that's quite different than trying to shoehorn threading or multiple CPU support into FreeDOS. I don't see the lack of hardware support on modern hardware as a big threat. Emulation and virtualization will protect us from lower level hardware changes for a long time to come. If anything we should be careful to ensure that VirtualBox, QEMU, etc. don't drop any features that we need to boot FreeDOS. (People who are required to use FreeDOS on bare metal will see this differently.) What I do see as a threat is the lack of people who know how to code under DOS, whether that be applications, TSRs, device drivers, etc. We are never going to get cutting edge software on DOS; those days are gone. But we need to attract more hobbyists, even if we have to disguise FreeDOS programming as another form of embedded programming. FreeDOS needs to embrace the retro-computing crowd; they have the hardware that needs things like FreeDOS and the spare time to play with it and push the limits. We need to clean up our documentation, improve our install and updating process, and generally do things that attract new users. With new users comes more hands, which we really need to keep things alive. We need to make incremental improvements to the FreeDOS distribution and do more frequent releases. Seeing FreeDOS 1.1 make it out was nice, but there was a few year gap there. If there is another 5 year gap between releases is anybody going to care about FreeDOS? My personal plans ... I'm trying to make network programming under DOS easier by providing a pretty complete framework for doing it. I've also picked my projects carefully to be both useful and to try to grab some attention to show that DOS, although not current, is still capable of some pretty neat things.
Re: [Freedos-devel] FreeDOS Roadmap: (Was Getting started
Re: FreeDOS vs. DOS-like operating systems There are plenty of DOS-like hobby projects out there. But without applications, they are pretty limited. I think a lot of the value in DOS and FreeDOS is the ability to run existing applications. So we need to decide on what we are trying to do; are we going to morph FreeDOS into yet another hobby operating system that is only slightly compatible with existing software, or are we going to keep it an open DOS clone? Re: Protected mode networking Networking provides the most value when it is an integral part of the operating system. Otherwise, we just have disparate applications that bring their own library code that the OS is unaware of. Even just the limited fix the libraries solution does not work because many of the networking applications are stuck in the 90s. The application code needs to be fixed too. In general, networking needs much more focus; the libraries really are not the problem. mTCP is a poor example to use; it is a personal project with a very specific set of goals. I was not happy with the TCP/IP code that I found and I took the radical step of writing everything from scratch. That approach is not scalable and I do not advocate. mTCP and FreeDOS are two different projects with different roadmaps. Re: Emulation environments We're going to have to face reality one day; hardware will move away from FreeDOS faster than FreeDOS can keep up with it. Unless we can attract a lot more interest in hard-core, low level programming skills then emulation will be the only way to deal with this problem. Re: Documentation Documentation for DOS is out there but it is so scattered and so disorganized. You have to know what you are looking for and where to look for it. The forums at BTTR software provide a good place for people to talk about programming. There are still Usenet forums out there that are active. There are other web forums. It is terribly fragmented. We need a DOS programming Wiki that can get people started. Things like what development environments are available, primers on real mode vs. protected mode programming, where the good libraries are, reading lists on where to look for more, suggested books, etc. The network redirector interface is a poor example to use; it has never been properly documented. If you have the 2nd edition of Undocumented DOS then you can get pretty close to it. There was a new project announced here recently that used it to provide file system access under VMWare. I have looked at it a few times to implement my own version of a network file system and I've just decided it's not worth the effort. Mike -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Roadmap: (Was Getting started
I have not done the survey in a while but I have found a lot of the older networking applications to be sorely lacking. The WATTCP based FTP clients that I looked at did not support passive mode connections and had horrible user interfaces. NCSA Telnet does not run on 8088 class machines; it's FTP server assumes a default port and does not understand PORT or PASSIVE FTP commands. A lot of the applications are inconsistent in their support of DNS and DHCP. Retrofitting existing applications to use a new TCP stack is like putting a supercharger on a lawn mower engine. Somebody still has to go in and fix the lawn mower We can argue the merits of the existing applications, but I'd rather talk about the road map. The road map said protected mode networking among other things. I'm trying to figure out what that means, and more importantly, suggest that just changing the networking library isn't going to help. We need more focus on networking in general. Mike -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS JetDirect driver
My understanding of the printer problem leads to believe this is not terribly easy. If every program out there uses the BIOS interrupts to send data to the printer, then it is pretty easy - you install a handler to intercept the BIOS calls and buffer the outgoing data elsewhere. The outgoing data then gets sent via a network to the printer. A TSR is not really even needed; you can have a standard program do this, shell to DOS, and then run the program to be intercepted from there. Not as convenient as a TSR, but much easier for debugging. However, if a program bit bangs the parallel port directly you can't capture that output. I don't know of any technique that allows one to intercept raw port I/O commands, unless you are running in a virtual machine (virtual 8086 mode included). Then the host operating system technically can intercept raw port I/O. The mTCP netcat program can be used to send the contents of a file straight to a printer. I think the HP JetDirect stuff (often found on other printers) is pretty crude; it is just an open port and there is no protocol or handshaking required. Mike -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS JetDirect driver
I don't pretend to make judgements on what is sane or not sane. I'm merely pointing out that if the BIOS interrupts are not used then the task is not feasible. Your point about the viability of NET USE printer commands is taken, and probably confirms that this is a more than feasible project. I suggested the shelling technique for somebody who wants to experiment with hooking the BIOS interrupts but is not ready to tackle the TSR portion. Too big depends on the program being used; there are many programs that will still load and run even with another 64K missing from RAM. Let's leave that question to the person who decides to tackle the project, eh? My Brother laser printer (HL 5370DW) which emulates Epson FX codes, PCL and PostScript just printed a PostScript copy of my 2002 family christmas letter from DOSBox using the following command: nc -target 192.168.2.20 9100 -bin \xmas.ps Lots of fonts and formatting, an embedded image or two, etc. in a 3MB file. You are limited to what the printer understands, but I think I've demonstrated that you can safely send ASCII, PCL, PostScript, or whatever your printer supports. Mike -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Do not use any code from ms-dos release!
On 4/24/2014 12:05 PM, Charles Belhumeur wrote: snip You really need to stop using questionable language on public mailing lists. The rest of us do not want to read your rants, especially when they are laced with words that do not belong here. It is offensive. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Do not use any code from ms-dos release!
On 3/26/2014 11:11 PM, Charles Belhumeur wrote: Tough line to walk folks! You wanna clone DOS but yet you don't want to be tainted by any suggestions you owe anything to DOS! Think that over a little. Say it to yourself and see how it sounds. Sure it sounds funny, but the funny part is not what you think it is. You clearly fail to acknowledge that DOS has been cloned already, and not just by FreeDOS. The message is that if you plan on contributing to FreeDOS it would be best not to be tainted by looking directly at MS-DOS source code. That same rule was enforced for the DR DOS developers too. It would be especially silly since this is the 2.0 version, which was the first usable version but it is still quite a long way ways from the far superior DOS 3.3 or DOS 5 versions. This is a potential legal issue. The message is clear and not contradictory in any way. Do not jeopardize FreeDOS's clean lineage by looking at non-open source code and then trying contributing to FreeDOS. It doesn't matter what the OS is for a lot of stuff. The Intel chips and architecture are what they are and they determine that any and all OSs have to have some source code in common at the machine or Assembler level. I kinda get a kick out of the LINUX crowd thinking the have a different platform than a WIntel box. Don't you think that the existence of OS/2 in the past and the growth of Linux had something to do with the way Windows looks today? Sure. Operating systems have some common concepts. But I think that a lot of the improvement we have seen in Windows in the last 15 years comes from people seeing Linux working on the same exact hardware and not crashing when you look at it the wrong way. Linux is about more than building another operating system. It highlights a great alternative way to build software. You seem to have missed this, and the general concept of open source software. After three decades of using computers I've seen most of the OSs, apps, etc. Worked on niche stuff like programmable logic controllers and the like. Things a lot of CS types don;t see. I really don't have any loyalty or preference for any of it. When I have an IT project in front of me I do some research to find the best current tools to apply whoever makes em. Thats my interest in DOS. The modern OSs get in the way of simple tasks and just overcomplicate some things. None are the best solution or all things. Windows 8 promo song All you wanna be is Everything at once! explains a lot about why its tanking. No platform or OS can be all things and all solutions or apps. Stupid to try. Stupid to be loyal to any of it! We don't hear squat about the OSs or apps or any software for a lot of embedded IT in our lives like microwaves and cars. Why not? Good thing MS isn't involved in software development for automobiles! Can you imagine cars and trucks having deal with Windows 8 or Vista? Where do I put the key in now? How do I shut it off now? Charlie B. You sound like a user. See the freedos-users list. This list is for people how are invested in the success of the platform. Contributors. I'm sorry if that sounds harsh but I'm making a point. Reread your email and think about how the rest of us enjoyed your unique perspective. It is inaccurate and rude. Mike -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS development sense
On 1/23/2013 11:42 AM, Jim Hall wrote: Hi. teogum replied to your other email on this topic, but here's my contribution. Today, FreeDOS is often used by three types of users: 1. People who want to play old DOS games 2. Developers, to run embedded systems 3. Businesses, to run legacy DOS software I would add a fourth category to that - people who maintain old IBM compatible PC hardware for their hobby, which is usually vintage computing. If we split hairs too much there could be an infinite number of users, but I think that group is large enough to stand alone. I might also add a fifth group - people who need a minimal bootable system to apply BIOS or other firmware updates. We get a lot of requests on the mailing lists for people looking to put FreeDOS on USB sticks, and often it is for this purpose. There aren't usage numbers for FreeDOS like you can get for Windows or Mac, which typically equate to numbers of licenses sold or number of Macs sold. But I can tell you about how many times the FreeDOS distribution was downloaded. I've been keeping track of downloads since the FreeDOS 1.1 release in January 2012. We're seeing 40,000-42,000 downloads per month over the last few months. Here are the number of downloads of the FreeDOS distribution per month in 2012: snip And so far in January 2013, we have had 22,991 downloads of FreeDOS 1.1. By the end of January, that should be almost 31,000 just for FreeDOS 1.1. -jh I am surprised that there are so many downloads. When you think about the number of copies of PC DOS and MS DOS copies floating around, that makes for a *large* number of DOS users. Most of which are probably occasional users, but still that is very impressive. Mike -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] mTCP 2012-05-30 is available
It has been a while and I've accumulated a lot of changes and fixes. Here is what you can look forward to: * Power awareness for virtual machines and laptops *IRCjr fixes to improve compatibility with more servers *Howto style documentation for setting up SLIP and PPP with mTCP *FTPSrv requires significantly less RAM *FTPSrv can be made to exclude certain drive letters *Telnet now supports Xmodem and Ymodem uploads and downloads *More newline handling fixes for Telnet (I think I got it right this time!) *The FTP client will send files much faster now - 10 to 34% has been measured Everything is available at http://code.google.com/p/mtcp/ . Enjoy! Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Development Idea
On 5/5/2012 1:27 AM, Martin Kelly wrote: What comes across to me is that if you remove the what i was suggesting entirely from the equation... That a) it all seems like to much effort and its much easier to whinge about the current compatiblity issues than try and implement a possible solution or b) You don't want to because your afraid of breaking what already exist... I find both in either case rather pessamistic. To me i would much rather spend the energy to experiment the worst that can happen is it doesn't work in which case your put back to the current situation. Or alternatively you find something new out that a) can provide a new feature/s for DOS. As Rugxulo as already mentioned is it such an insane idea to implement or attempt to implement a new filesystem or is it that developers would much rather be lazy about it all. (No offense intented) To me it comes across as the latter. Much rather find excuses for why it won't work than reasons for how to make it work. I have been trying to inject a bit of reality to this and it doesn't seem to be working - If you break compatibility with existing DOS, you break compatibility with a lot of applications. A lot of people use DOS because it runs the applications that they want to run. So you might wind up with a technically better operating system with few users. - The level of effort and technical skill you are talking about is enormous. You can have great thoughts and sketches of what the future should be, but redoing even a simple OS like DOS is not trivial. And then you still need the applications. Here is a small example - I started working on mTCP in late 2005. It was 2008 before I had an application suitable for an end-user to run. In 2011 the code was finally clean/stable enough to release. Right now the next version is over 36000 lines of code and comments. It's taken thousands of hours over the last six years to do this. That includes 228K of user documentation and another 60K of developer documentation, which is woefully inadequate and needs more time. Am I lazy for pointing out the level of effort and skill required to implement some of your ideas? How much effort do you think it takes to build a better DOS with the features that you are talking about? How about the applications to go with it? Do any other current active developers want to chip in with their experiences? Georg? Eric A.? Jack? I think it would be helpful to hear how much time it takes to maintain and develop applications and drivers for the existing DOS that we have. I've been spending my time and energy where I think it is most productive and does the greatest good. It's your time and energy to spend as you please, so go ahead and go big. But I really don't think you have an idea of the size of the undertaking. Don't be disappointed if everybody else doesn't jump right away - it is for you to lead and build that momentum. But please be more aware of what you are asking for. Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Development Idea
Rugxulo, You read into things too literally at times ... ;-0 The 808x series of processor was segmented. It was used on a machine that reserved a portion of memory for system BIOS, system BIOS extensions, and video RAM. The first versions of the operating system (DOS) did very little to mask the architecture of the PC. If you wanted to read the keyboard or draw the screen, you could use the DOS functions which were very incomplete in their implementation. Or you could go directly to hardware. Except for a few small warnings (please don't go to BIOS, it might break your application on a completely non-conforming machine), many people went straight to the hardware. It only supported contiguous chunks of memory, making it hard to deal with the transition to machines with more than 1MB. So now you have a thin shell of an operating system that does nothing to avoid exposing the hardware to the end applications. And we've been applying one kludge after another on top of that ever since. For example, you mention Win 3.0 (DPMI). DPMI is a kludge to allow DOS applications to use more memory while still being able to invoke BIOS functions and DOS kernel functions. Windows and OS/2 don't add multi-tasking to DOS - they let several copies of DOS run side-by-side in what is effectively a dedicated virtual machine! If I lock you in a prison decorated to look like 1988 you'll think you live in 1988 too ... PC DOS 6.x and 7 still support FCB based programs. Yes, people should still use file handles. But my point was that once something gets added, it never gets removed no matter how archaic. If you want to modernize DOS even just to support more current hardware you are going to have to duplicate a lot of work that has already been done for drive controllers, video cards, USB controllers, BIOS bootstrap requirements, etc. Like I said, that would be redoing a lot of the work that has already gone into Linux. If you want to really modernize DOS you are going to have to fix or break a lot of things that exist today. You can implement a simple OS that uses the INT 0x21 programming interface, but if it doesn't run existing software (because you have a 32 bit kernel that doesn't handle segment wrapping correctly), doesn't load existing TSRs, has a different memory map, and doesn't allow direct access to hardware, is it really DOS anymore? Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Development Idea
Just my opinion, but here it is ... Trying to do a new OS that resembles DOS but has modern features is not feasible and not going to happen. The biggest problem is DOS compatibility - as soon as you start messing with the memory management, APIs or fixing the bugs then existing DOS software will break. You can have a DOS-like operating system that supports INT 21 calls, direct access to hardware, and some other attributes, but if you can't load DOS device drivers, TSRs, or take advantage of weird DOS specific features then it really isn't DOS anymore. DOS is so intertwined with the early PC hardware that it is nearly impossible to modernize it. DOS also tried to remain backwardly compatible to a fault, hence the support for FCBs even though file handle based I/O should have replaced it back in the mid 80s. It's a kludge on top of a kludge, and that's what makes it DOS. Fixing the kludges makes it something else. I think that most of us who have thought about DOS have thought about how to provide modern hardware and peripheral support - video cards, USB, hard drive controllers, etc. And most of us probably don't want to re-invent Linux again. If we don't use another OS as a base then we need to re-implement all of those device drivers in DOS, and that's not feasible either. We have a limited number of people programming. I think our resources are better utilized by making sure we have modern software for DOS that keeps the machines and DOS relevant. Trying to fix architectural limitations of DOS is futile - you might as well just start with text mode Linux. Mike -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] COMPRESS offset problem
On 12/27/2011 5:43 PM, Ralf A. Quint wrote: At the very least, we seem to have different definitions of DOS-friendly here... ;-) I would have to agree on your judgment of the comp.lang.c usenet group though, that group doesn't serve any practical use whatsoever...:-} Dropping a problem on a list that is only of marginal interest to the list and then expecting the list members to do the debug work for you is kind of poor behavior. I thought that sending him to comp.lang.c was a way to get him exiled to never-never land ... apparently you were serious. The problem with this particular user and project (which I will not mention by name) is that he has been trolling the Usenet groups looking for help with this particular project. If you read the message threads he has a concept for what he wants, but not much of a way to do it himself. And his methods of trying to solicit interest and help are making people irritated. Check out recent postings in comp.os.msdos.programmer if you need the context. Sending him to the Watcom usenet groups won't go over well. They are not terribly active and their patience will wear thin even quicker. Some references to 'How to program in C for beginners' would be far more appropriate. Mike -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] COMPRESS offset problem
On 12/28/2011 9:23 AM, Michael B. Brutman wrote: On 12/27/2011 5:43 PM, Ralf A. Quint wrote: At the very least, we seem to have different definitions of DOS-friendly here... ;-) I would have to agree on your judgment of the comp.lang.c usenet group though, that group doesn't serve any practical use whatsoever...:-} Dropping a problem on a list that is only of marginal interest to the list and then expecting the list members to do the debug work for you is kind of poor behavior. I thought that sending him to comp.lang.c was a way to get him exiled to never-never land ... apparently you were serious. Correction/misquote - You (Ralf) did not suggest comp.lang.c .. Mike -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] final preview for FreeDOS 1.1 release
Forgive me, this is going to be long ... I made a few attempts at creating a new virtual machine and installing the preview. It was a bit rough around the edges, especially from a new user perspective. If it took me a few tries to get things installed then something is amiss. Below are some usability notes I took as I scrapped what I had and restarted from scratch. I know I'm going to be off the mark on some things based on my inexperience. Booting the ISO: The default timeout of 5 seconds before booting the Live Environment mode is way too short. A new user would want to read the screen to see the options; right now it will start booting to the live environment and confuse them. Install to harddisk: (My drive was not partitioned or formatted yet.) Welcome to FreeDOS 1.1 Setup Destination: checking if FDISK can detect any harddisks This check correctly found the hard drive with no partitions. But the screen cleared too quickly; there should be a pause to show the results of the fdisk check. The next screen allows you to run FDISK to modify the hard drive partition table or load additional drivers for optical drives. It tells you installation will continue in 15 seconds. Once again that is too fast, and there is no count-down timer to show you that the clock is ticking. There is also no way to pause it if you need additional time to read or decide. Running FDISK was uneventful. But after FDISK exited it went back to the previous screen (run FDISK or load optical drivers). FDISK gives a warning about needing a reboot but does not enforce that. The install script should terminate by telling the user that the machine is going to be rebooted to restart the installation and actually reboot the machine once the user acknowledges it. (No count-down timers!) (At this point I forced a reboot to make my partitioning changes stick.) Resuming where I left off ... Mysterious a and 1 appear after the 15 second period. Next comes a prompt about Buffering installation files, press N to skip: There is no explanation about what is going to be buffered, or what the ramifications are of saying no. There appears to be a timeout period that but it is not stated, and there is no countdown. Next the RAM disk program runs and creates a drive (G: in my case), but all of the operations to create directories and copy files to G: fail. All of the messages are out there - it looks really ugly and would scare the hell out of somebody. (I'm not a newbie but even I felt the need to stop and debug what just happened, not realizing that the failures did not affect the ability to install.) Any operation to drive G: gave an Out of memory error. The last prompt said: Type E:\Setup to start installation of FreeDOS 1.1. Batchfile 'D:\AUTOEXEC.BAT' not found. Again, not confidence inspiring. D: was completely empty - I am not sure what is supposed to be there. Starting the install with E:\Setup ... After selecting the language there was a foul stream of Run chkdsk: Bad FAT I/O: 0x0001 messages before the installer cleared the screen and reported that the drive need formatting. The latter part was good, but the foul stream of error messages really should be hidden. (And whatever caused them needs to only show one message at most, not the same message over and over.) It tells me that it is going to create a FAT32 filesystem. I formatted the drive to be FAT16. I suspect this is an error in the message text, and that it really didn't check the partition type. The user should get a chance to review the messages from the format ... there is no pause. Continuing with the installation 2) Change installation mode should tell you what the current mode is. It should also be above 1) Start installation of FreeDOS 1.1 Final, forcing the user to read through it and consider it. The screen has plenty of room for help text as the user moves through the menu options. Selecting option 1, a mysterious Syntax Error appeared on a blank screen before continuing. Not confidence inspiring. The package selection screens should have some basic help - using the arrows to move, 'X' means selected, etc. Boot was missing a description - the rest were fairly spartan. Done probably should be Continue to the next step. Second package selection screen: Everything has an 'x' at the end of it which makes the 'x' kind of meaningless. If the description is too long it corrupts the right border with extraneous letters instead of continuing on the next line. (Dosfsckx does continue to the next line, but the screen formatting is borked.) Once again, Done should be Continue to the next step. And that should provide a warning that package selection is done and file copying is about to start. (And there should be an option to go back and alter if there are last minute doubts.) After what looks like to be a complete file copying stream another
Re: [Freedos-devel] final preview for FreeDOS 1.1 release
Bernd, I am going to try to snip the non-relevant (or the understood/agreed upon parts) so that this doesn't get too out of control in terms of length and lost trains of thought. I used the latest VirtualBox (4.1.8) which is pretty close to VMWare in function. I did not see anything that I suspect was related to VirtualBox but I will try again in VMWare to be certain. I defined the virtual machine to have 64MB of memory and a 500MB hard drive. VirtualBox can emulate the PCnet Ethernet adapter, which is convenient for us because VMWare does too. On 12/27/2011 1:19 PM, Bernd Blaauw wrote: Op 27-12-2011 17:03, Michael B. Brutman schreef: This check correctly found the hard drive with no partitions. But the screen cleared too quickly; there should be a pause to show the results of the fdisk check. Ah, so at least JEMMEX works for you, didn't build a failsafe around that yet. If a harddisk is found is shown again in text form at the central menu but I agree it could be more clearer. Just out of curiosity - Is JEMMEX (or any other expanded memory manager) really required for an install? My impression of the install process is that it is mostly a file copy or unpacking exercise. For the widest compatibility not requiring an expanded memory manager would be a great plus. The next screen allows you to run FDISK to modify the hard drive partition table or load additional drivers for optical drives. It tells you installation will continue in 15 seconds. Once again that is too fast, and there is no count-down timer to show you that the clock is ticking. There is also no way to pause it if you need additional time to read or decide. I thought 15secs to be sufficient for a single-choice, but can make that longer if desired. Fifteen seconds if you know what to expect. A newbie or a person who installs infrequently is going to have to read the questions and ponder them for a few moments. Do they need to fdisk again, or are they satisfied with what they had? Do they think they need to load additional optical drivers? From a usability standpoint there should be plenty of time, a visible countdown of some sort, and some way to pause the countdown. (This applies in many places.) An advanced user can always blast through without waiting. I put myself in the infrequent installer category, and I needed more time. Running FDISK was uneventful. But after FDISK exited it went back to the previous screen (run FDISK or load optical drivers). FDISK gives a warning about needing a reboot but does not enforce that. The install script should terminate by telling the user that the machine is going to be rebooted to restart the installation and actually reboot the machine once the user acknowledges it. (No count-down timers!) How was FDISK uneventfull? I know v1.31 has some MBR-detection issues (blank disk in VMware for example) so using the older 1.21 one. There's an issue if FDISK can't find any disks, then it won't reboot either. Using FDAPM instead (there's a couple of hidden options basicly, like 'r' or 'm' or 's'). I'll see what I can change. It just worked - no problems. The blank virtual hard drive in VirtualBox did not confuse it all all. After Fdisk runs (and changes are made) the installer should lead the user to reboot the machine. At the moment it gives a warning that the machine should be rebooted, but then it returns to the previous screen where it asks if you want to run fdisk or load drivers. Instead it should lead to a screen that says 'Reboot now, or go back to fdisk and play some more'. How the reboot gets done doesn't concern me too much as long as the user knows they need to reboot before trying the install again to make sure the partitioned disk is now visible. Resuming where I left off ... Mysterious a and 1 appear after the 15 second period. Next comes a prompt about Buffering installation files, press N to skip: There is no explanation about what is going to be buffered, or what the ramifications are of saying no. There appears to be a timeout period that but it is not stated, and there is no countdown. I'm not sure how to implement a countdown, it's not an option in CHOICE program (and neither is suppressing the selected input char apparently, thus explaining the 'a' (auto-mode) and '1' displayed). Do we need upgrades to CHOICE? I can do that. ; - 0 Next the RAM disk program runs and creates a drive (G: in my case), but all of the operations to create directories and copy files to G: fail. I've seen this on my family's laptop during Christmas and will have to debug this, it's not happening on my machine. Quite odd. What happens is that a RDPREP.BAT file is being called on the CD that loads SHSUCDRD. The SHSUCDRI program (duplicate disk) didn't work for me so I went this route. I can try disabling this routine if that would be more failsafe. Ok - I'm not alone here. A lot of machines might
Re: [Freedos-devel] Emulating Keystrokes
On 11/18/2011 4:24 PM, Ralf A. Quint wrote: In particular for games, I would not expect that they necessarily use INT 16h functions to read the keyboard, specially when they come with their own mapping of the keys. You might have to get a level lower probably, messing with intercepting/simulating INT 09h to work directly on the scan codes instead and then probably make sure that you do not have any keyboard driver like KEYB installed either... Ralf And remember, if you go to the INT 09 level then you need to be careful about which set of scan codes a machine recognizes. Older iron (what I specialize in) won't see or understand the newer keys on the extended keyboards. (The PCjr gets around this by mapping the scan codes from its unique keyboard to standard PC and XT scan codes before invoking INT 09. Mike -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Testing for valid drives
On 10/3/2011 6:42 AM, Eric Auer wrote: No, it actually behaves as expected if you see this in DOSEMU: Only FAT drives have a DPB, but network / redirector / CD / DVD drives do not, so as RBIL already says: FFh invalid or network drive ;-) I missed the network drive part, which makes the code is incorrect. However, I tested FreeDOS in a virtual machine to confirm the bug, and no drives are showing up there. That seems to be an error - there is at least the virtual hard drive (C:) which is a FAT device that should have shown up. So what should be a minor bug (missing network drives) is missing all drives under FreeDOS if I use INT 21,32h. What am I missing? Mike -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Freedos and lack of drivers
On 9/14/2011 7:31 AM, Travis Siegel wrote: Mike, I like your suggestions. One thing that always bothered me about dos versions that have come out since ms dropped the ball is their complete lack of inovation. I realize there's only so much that can be done if you're intending to keep 100 percent compatibility, but still, it's not hard to imagine such details as enumerated here. One thing I wonder is why nobody builds a dos multitasker that simply spawns a new virtual 386 machine for each new dos task. That would keep 100 percent compatibility, and still allow complete and free multitasking. The virtual 386 machines would take care of virtualizing keyboards and video output automatically, since it's all built into the 386 hardware. I'm fairly certain, none of that ability has been removed with the newer cores and such. I see no reason why this sort of thing couldn't work. I'm not positive, but I think this is the approach vmix386 took, and why it worked so well (at least with my testing) it would be fantastic to have such an os. What I suggested earlier can be implemented using the virtual 386 mode. The difference is that instead of running several virtual 386s independently, the DOS kernel within the virtual 386 can coordinate/share resources with other DOS kernels running concurrently. This gives the illusion of true multitasking in DOS while keeping separate hardware resources so that the ill-behaved programs we love so much can still touch all of the hardware and memory in their address space. The other, more modern alternative is to use KVM/QEMU and the hardware support built into the more recent x86 processors. This setup is used by other virtualization environments, and KVM/QEMU have the advantage that the guest OS (our DOS kernel) can do magic syscalls to ask for an assist from the host OS (Linux). It allows us to move a lot of the DOS kernel into KVM/QEMU where you have a much better programming environment (Linux), resources, etc. Another thing I wonder, is why it is that nobody has built anything that allows executing of multiple oses on a single computer, using one cpu core for each os, thereby allowing each os to run natively on it's own cpu, thus eliminating the need to vertualize anything (except perhaps output and input), but then each and every os would have it's own cpu, and all of them would run at full native speeds. Then you could have as many oses running as you have cpu cores to handle them. (still waiting) I guess someone will do it eventually, but until they do, I'll stick with my osx machine, and my several dos boxes scattered everywhere. :) I'm sure somebody does that, but that is more of hard partitioning scheme than a virtualization scheme. PowerPC machines can do that (LPAR) as do large IBM mainframes. Mike -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Heads up: DOS ain't dead forum is closing
Here is the link to the announcement: http://www.bttr-software.de/forum/forum_entry.php?id=10488 To me this is a serious problem - losing a piece of the DOS community is bad. Losing the place where a lot of the programmers hang out is even worse. Mike -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Freedos and lack of drivers
I have been thinking about what a more modern DOS would look like. Some ideas ... - A task would look a lot like a single instance of DOS running today. The address space of a task would look the same, so it would have the interrupt table, BIOS area, video display buffer, expansion ROMs, system ROM, and extended memory that you find on a DOS system today. (Kind of like a running instance of DOSBox, but with better device and hardware emulation.) - MS DOS has its own concept of process, which is an instance of a running executable. That concept remains unchanged. Multiple processes live within a task (as defined above) just as they do today. - The DOS kernel supports most (if not all) of the standard DOS functions. As there is an interrupt table and system ROM, BIOS functions are available as well. - Multiple tasks could be started and running. But they are logically part of one machine and one OS, not just separate instances of an emulator. The underlying kernel is a bit more sophisticated: - There is a shared filesystem for the machine. If that filesystem is not FAT then it is made to look like FAT by the time the DOS function calls run. - Memory mapping is used so that the tasks exist in different address spaces, and thus are protected against each other. Memory mapping is also used to give the illusion that each copy has its own video buffer so that direct screen writes and other normal practices are not problems. - The DOS portion of the operating system that is visible to the user applications is a thin wrapper that calls into the real OS. That keeps the memory footprint of the DOS kernel in each task minimal. - There is a real networking stack that can be used, and is shared across the entire machine. Additional DOS function calls are defined to use it, or a packet driver used a shim is used to support existing applications. - The kernel provides some other services that we are missing, like cut n paste support between the different tasks and inter-process communication. Another way to look at this is that you have a real operating system like Linux with a new (or better) DOS emulator. The DOS emulator takes some pain to try to emulate a real machine; keyboard interrupts, timer tick interrupts, 8250 and 16550 device emulation, etc. The difference is that unlike running multiple instances of DOSBox in separate Linux processes, the emulator allows some sharing of common state and data between the different emulated DOS tasks. I can't see adding all of this (or even 1/10th of it) to FreeDOS. But I can see starting with a fairly stripped down Linux base and doing some hardcore development work with KVM to build this. Riding on top of Linux takes care of our hardware compatibility problems and the emulator should preserve most of our existing software base. Mike -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] potential issues with freedos in virtual environments
In a not so long ago job assignment I spent a little time learning the innards of KVM, qemu, and virtualization technology in general. The virtualization environments are going to do a good job running your instructions on real hardware. All modern hardware has support for doing this, sometimes even very sophisticated support for shadow page tables. (Luckily DOS doesn't need all of that.) Things get more complicated if you run a privileged instruction; that requires an assist from the VM for security reasons. When a VM blindly emulates hardware things slow down. For example, the AMD PCNet emulation that VirtualBox and VMware provides requires both of those VMs to sit and emulate each and every I/O operation from the packet driver or networking software. The same thing goes for IDE emulation, and any other hardware emulation. The better virtualization environments realize this and use paravirtualization. In a nutshell, the guest operating system runs special device drivers that know how to hit magic buttons in the VM. In the case of the network adapter, instead of doing a whole bunch of privileged I/O operations to send a packet a paravirtualized driver can press a magic button on the VM, telling it where the data is and how to send it. The partitioning support on all of the big IBM Power machines use this trick. When VMWare provides special drivers to Windows for file sharing and screen handling it is doing the same thing. Ultimately we're going to need to have DOS device drivers that know how to interact with the various VMs. In the case of VirtualBox, that should not be a large problem - the interfaces are in the open source code. For VMware and closed source VMs it might not be possible unless the interfaces are published. Mike -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX and XFDISK
On 8/1/2011 7:31 PM, Bernd Blaauw wrote: Op 30-7-2011 15:29, dos386 schreef: Got the answer ??? - LZMA decompressible on 8086: YES - LZMA vs NRV/UCL: LZMA (much?) slower decompression - Ultra-Brutal-Effect: much slower compression, no performance penalty on decompression (?) I did a quick test here by looking if UPX --ultra-brute --lzma --8086 generated smaller binaries than the one which are distributed in the MTCP/UPX file. And indeed smaller, so think Mike used default UPX settings ( --best --8086). It's indeed quite likely LZMA and UltraBrute options may at least cause slower loading (more decompression time required) or not work at all on 8086. If it does work however, awesome :) LZMA versus other alghorythms: likely slower indeed, but wasn't tested as Mike tested against uncompressed binaries (with longer DISK-reading time yet no time wasted on decompressing ofcourse). I'm willing to get out the stopwatch and retest now that I know more. There was a question about the which of the algorithms (LZMA, NRV, UCL) is safe for GPL software. A quick review of the UPX web site did not give me a clear answer on which one was used when I specified -9 --8086 for options. Does anybody know off the top of their heads? Mike -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Testing evaluating the 1.1 release
On 7/15/2011 11:33 AM, Bernd Blaauw wrote: Op 15-7-2011 5:08, Michael B. Brutman schreef: - How do I use the new installer that Jim has been working on? It's in the new ISO that I plan to upload by Sunday evening. Still need to work out some things to make it a smoother experience. The initial menu showing which CD drives were found for example (which I also should add plain directories to, but that's more difficult). Good - I await the next revision. I'm trying to do my part here by testing it .. - Are all of the binaries always put into the one bin dir? I expected the optional packages to be separated into subdirectories, not lumped in with the critical OS commands. All is together. Nothing is preventing an additional directory called EXTRA, putting subdirectory PACKAGES below it and a BASE directory below that, and then install from that location, allowing a 2nd directory. The following is just a matter of personal preference and/or opinion .. On all of my machines (DOS, Windows and Unix) I try to keep the optional packages separate from the core OS functions. So DOS will live in /DOS and nothing else will be in that directory. Smaller utilities wind up in something like /utils/text, /utils/disk, /utils/zip, etc. If something has a lot of files that deserves it's own directory. mTCP usually lives in /mtcp or /packet/mtcp depending on what other networking code I have installed. I can see where DHCP, FTP, PING, SNTP, and TELNET could be considered core OS functions so I'm not entirely opposed. It's just different than what I'm used to seeing, not just on DOS. - I noticed the PCNet packet driver, which was a happy coincidence because I was installing under VMWare. Has their been any thought to including other common packet drivers? FreeDOS 1.0 has lots of packet drivers, I didn't include them so far to keep the CD minimalistic. Rebuilding for every change on batchfiles can be a pain :) Does this mean that they will be put on the CD later, or that the user has to find a different way to get them on the machine? I think that every packet driver known to man probably fits within 1MB of space. :-) (Ok, maybe 2 ...) Is the intent of the CD to provide a minimal install? - Did I miss the option to install the WATTCP based programs? See above, minimising things. WATTCP programs are usually compiled as DJGPP programs, having kind of huge disk footprint compared to your drivers for example. Same question as above - the capacity of a CD is quite large, and 12MB for an OS install image is tiny. As an end user I would much prefer that what I need is on the CD already even if it means a larger download size. (Or give me a choice of ISO images to use.) I'm new to this, so if this is already addressed in some way then forgive me and just point me on my way ... - Do I have time to do a minimal mTCP configuration program that can be used to walk users through setting up the configuration file? Ofcourse, knock yourself out :) I noticed the problem with the improper CR/LF in the mTCP configuration file that you reported a week or two ago, and I assume that we can just fix the original file. Depending on your time table I can either fix DHCP to be more tolerant of improper new lines in files or I can try to do something more comprehensive that looks like an installer. In a perfect world the installer would just prompt for a few things like the IRC user name, FTP buffer sizes, MTU size, etc. If that doesn't happen in time having those fields in the mTCP config file (but commented out as I do in the sample) would be a reasonable substitute. BTW, I'm happy/honored to be part of the group. I just want to ensure that the mTCP code looks/behaves more like the OS so that it doesn't cause usability problems or stick out too much. It's not a full networking stack, but the idea of a coherent set of networking utilities available at install time with the OS is very appealing. Mike -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Testing evaluating the 1.1 release
I just took my first pass at installing 1.1 using the ISO image that Bernd Blaauw provided a few days ago. I got it done, but it was not without a few problems. I'll assume those are user errors until I can prove otherwise. Some general questions and comments from a newbie: - How do I use the new installer that Jim has been working on? - Are all of the binaries always put into the one bin dir? I expected the optional packages to be separated into subdirectories, not lumped in with the critical OS commands. - I noticed the PCNet packet driver, which was a happy coincidence because I was installing under VMWare. Has their been any thought to including other common packet drivers? - Did I miss the option to install the WATTCP based programs? - Do I have time to do a minimal mTCP configuration program that can be used to walk users through setting up the configuration file? Mike -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] UPX compression for DOS apps
On 7/10/2011 10:25 AM, Bernd Blaauw wrote:
Mike,
do you have any experience using UPX (executable file compressor) on
your programs? I'm wondering if
1) programs still load properly for you on 8086
2) smaller disksize + in-memory-decryption faster than loading entire file.
I'm pretty sure the compression program itself is 386+ or 586+,
but compressed executables should be 8086+ if used with proper options.
(upx.sf.net ) , upx --best --8086 c:\mtcp\*.exe
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2010
UPX 3.07d Markus Oberhumer, Laszlo Molnar John Reiser
File size Ratio Format Name
-- --- ---
51974 - 32191 61.94% dos/exe dhcp.exe
39372 - 25975 65.97% dos/exe dnstest.exe
102256 - 56758 55.51% dos/exe ftp.exe
111996 - 58321 52.07% dos/exe ftpsrv.exe
87044 - 48833 56.10% dos/exe ircjr.exe
76430 - 44563 58.31% dos/exe nc.exe
40092 - 26488 66.07% dos/exe ping.exe
41660 - 27319 65.58% dos/exe sntp.exe
69230 - 40488 58.48% dos/exe spdtest.exe
86730 - 48854 56.33% dos/exe telnet.exe
-- --- ---
I tested UPX on one of the slowest machines that I have that has a hard
drive. On a PCjr with a NEC V20 and XT-IDE adapter UPX compressed
executables worked, but they took noticeably longer to start up:
FTPSRV: original was 2 seconds, with UPX is 5 seconds
PING: original was 1 second, with UPX is 2 seconds
The V20 makes the machine a little faster than a standard 8088 based
machine. The XT-IDE adapter is slow as far as hard drive controllers
go; on a real XT the delay would be more pronounced because the
controller is far better. But on an 80286 or better I'm sure that the
difference is not noticeable.
I think that most people are running on faster hardware with plenty of
storage space, so this is interesting but probably not worth making part
of the build process. (Is my instinct correct here? I think I'm one of
the few nut jobs on 8088 based hardware, because it's fun!)
On a slightly off topic note, I need to learn to build FreeDOS. I
suspect it doesn't like my PCjr and I'm going to have to fix that. :-)
Mike
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] File directory buffering and updates
I have a report from a user who is getting stale directory data when running the mTCP FTP server. They are running a TSR in the background which is updating a file once a day. If they connect to the FTP server and look at the directory they will see the date and size of the file at the time the FTP server started, not the most current values. Apparently a WATTCP32 based app has the same symptoms, but the Datalight Sockets FTP server does not. (I think the Datalight Sockets FTP server runs as a TSR, not a foreground app.) I use _dos_findfirst and _dos_findnext to read directories. These use function 0x4E. I expect that if there is a TSR modifying something in the background that calling the DOS function directly (as I am) should provide the most current results, but that is not what is being reported. Can somebody give me an idea of what I am missing? I am not sure what they would get if they tried to open the file and transfer it. I also don't know if the TSR is closing the file after each update - I imagine that leaving the file open would create problems. Regards, Mike -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mTCP FTP performance (Was: watcom tcp
On 7/10/2011 10:25 AM, Bernd Blaauw wrote:
Op 7-7-2011 13:58, Michael B. Brutman schreef:
Mike
Mike,
do you have any experience using UPX (executable file compressor) on
your programs? I'm wondering if
1) programs still load properly for you on 8086
2) smaller disksize + in-memory-decryption faster than loading entire file.
I'm pretty sure the compression program itself is 386+ or 586+,
but compressed executables should be 8086+ if used with proper options.
(upx.sf.net ) , upx --best --8086 c:\mtcp\*.exe
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2010
UPX 3.07d Markus Oberhumer, Laszlo Molnar John Reiser
File size Ratio Format Name
-- --- ---
51974 - 32191 61.94% dos/exe dhcp.exe
39372 - 25975 65.97% dos/exe dnstest.exe
102256 - 56758 55.51% dos/exe ftp.exe
111996 - 58321 52.07% dos/exe ftpsrv.exe
87044 - 48833 56.10% dos/exe ircjr.exe
76430 - 44563 58.31% dos/exe nc.exe
40092 - 26488 66.07% dos/exe ping.exe
41660 - 27319 65.58% dos/exe sntp.exe
69230 - 40488 58.48% dos/exe spdtest.exe
86730 - 48854 56.33% dos/exe telnet.exe
-- --- ---
That looks very promising - I will test it out. I imagine that
decompression time on the smaller machines is a little longer, but that
is offset by that much less disk I/O. And the smaller machines are
often tight on storage.
Mike
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mTCP FTP performance (Was: watcom tcp
On 7/6/2011 7:10 PM, Bernd Blaauw wrote: Op 7-7-2011 1:32, Michael B. Brutman schreef: mTCP FTP compares poorly to the native stack and FireFox there, but FTP is working in a very limited environment: * The TCP/IP socket receive buffer is tiny compared to the native network stack * You are doing filesystem writes 8KB at a time * You have a small virtualization penalty * The packet interface wasn't designed for high performance; every incoming packet requires a hardware interrupt and two software interrupts I'm happy with whatever I can get. My real hardware has an Nvidia chipset network driver for which no packet drivers exist, so sticking to virtual machines. I wonder if any PCI (or even PCI-express or onboard) network cards still support packet drivers. 8KB filesystem writes? odd. So it's: 1) download/transfer 8KB (8KB transfer buffer) 2) halt download, dump transfer buffer to disk and clear it 3) continue downloading. Not so odd. All comm code fills buffers and then processes the buffers. Unless you have a multi-core system you are always halting the processing of TCP/IP protocol handling to do your disk writes. Modern OSes with DMA support hide some of that by letting the DMA controller of the disk (and possibly the Ethernet controller if so equipped) do the byte copying work. But in the absence of DMA the host CPU does everything, and does it in a single threaded manner. Easier at least compared to having a 8KB transfer buffer plus a 'huge' receive buffer (nearly size of all of machine's conventional memory, a multiple of 8KB?) followed by only clearing the buffer if it's full or a file has been downloaded completely (whichever comes first). Your single buffer might be more efficient compared to transfer buffer plus receive buffer. Or perhaps I should stay silent hehe, failed miserably while learning about OSI layers and TCP/IP. I suspect that the Intel chipsets on PCI-X cards will work; their PCI chipset cards had working packet drivers and from a software standpoint PCI-X is identical to PCI. On the wiki at the Google project page I have three different PCI cards listed that are known to work. (And I'd like to hear about more.) In this environment we are entirely single threaded, except for the hardware buffering that happens on the Ethernet card. To receive a packet the path looks like this: - the card receives and buffers the frame from the wire - the card signals a hardware interrupt - the packet driver responds and either interrogates the card or copies the contents of the frame - the packet driver makes an upcall to the TCP/IP code - the TCP/IP code either provides a buffer or says 'no room' - the packet driver makes a second upcall to let the TCP/IP code know the frame is copied - the interrupt ends and the interrupted code resumes - the packet must now go through IP and TCP protocol processing The buffering scheme works at three levels: - Raw packet buffers (20 at 1514 bytes) - TCP receive buffering (8KB) - File read/write chunk size (8KB) Raw packet buffers are used by the packet driver directly. They are the critical resource; if you run out of those you start dropping frames coming in from the wire. TCP buffering is designed to pull data from those packet buffers as quickly as possible so that they may be recycled. (In the case where you have a lot of small incoming packets that is really critical because every incoming packet is allocated 1514 bytes whether it needs it or not.) The TCP buffer is organized as a ring buffer so it is more space efficient. The application reads from the TCP buffer and writes to the filesystem. All of this is still single threaded and for most systems the bottle neck is the disk access time, not the copying of data from multiple buffers. At a minimum all reads and writes to the filesystem should be done in multiples of 512 bytes; anything less requires DOS to do a read/modify/write as it writes data to the blocks of the filesystem. 1KB reads and writes were very inefficient to do - after some experimenting I found that 8KB was good. 16 or 32KB are marginally better. The buffer sizes generally are not larger because larger does not make that much of a difference in the performance of the filesystem writes and does have a negative impact on buffering. Long writes delay TCP protocol processing, causing incoming buffers to run low and delaying the sending of ACK packets for the received data. The major opportunity for improving performance is to send the ACK for the packet as quickly as possible, right after TCP goes through protocol processing but before the application tries to read the receive buffer and empty it. Getting that ACK out early keeps the flow of data constant and hides some of the latency the 'receive data/write data' cycle that is occurring. Another optimization I could make to this would be to have the FTP application handle
Re: [Freedos-devel] mTCP DHCP errorlevels (watcom tcp
On 7/6/2011 7:10 PM, Bernd Blaauw wrote: For DHCP I can imagine various errorlevels for different reasons: * missing MTCPCFG variable * MTCPCFG variable points to non-existing file * missing PACKETINT keyword in file * unable to write to MTCPCFG file (yay hidden/readonly) * packetdriver not loaded yet * static config found in MTCPCFG file * time out (no DHCP server found) * what else? invalid MTU size? Bernd I have resisted getting too detailed with the errorlevels because I would need to make them consistent across all of the applications. At some point I'm not going to control all of the applications, so I won't be able to enforce it. The user readable error messages are usually descriptive enough. (I might address this by reserving a block of error codes for the library, most of which would be used during startup.) We might have a small misunderstanding about the relationship between DHCP and the configuration file. All of the mTCP applications think that they are using a static configuration. They read the configuration file and use what they find. DHCP is a special case; it is the only code that will alter the configuration file. This allows me to keep all of the other code simple while still providing DHCP support; all of the other code thinks it is using static configuration and DHCP plays along with that fiction. Therefore, DHCP will usually find a static config in the file because it wrote the static config there the last time it was run. (If you are generating the config file each time before calling DHCP then finding a static config would seem like a reason to stop, but normally it is not.) Mike -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mTCP FTP URIs (was: watcom tcp
On 7/6/2011 7:10 PM, Bernd Blaauw wrote: That funny URI syntax was grafted on. What exact URI are you using? Are you adding ftp://; or just // ? FreeCOM (maybe also MSDOS command.com or 4DOS) seem to split arguments at the / level. See the FOR LOOP in my batchfile, with batchfile called as: ftp.exe ftp://ftp.xs4all.nl/pub/test/10mb.bin resulting in: ftp.exe //ftp.xs4all.nl (on which it chokes, not knowing how to handle //). Basicly there are 2 options: 1) find a way to strip the prepending // before feeding to FTP 2) allow FTP to accept them and strip it themselves, requiring code changes. Ah - I forgot to take the command line parsing into account. What happened to the ftp: before the // in this case? Let me see how this behaves on my other systems before deciding what to do. I don't want to build in workarounds for strange command line parsing into the code. A more general solution might be to allow the parameter to be quoted on the command line so that I can just handle standard URI syntax. Mike -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] mTCP FTP performance (Was: watcom tcp
Just for grins I did a little speed testing comparing mTCP running in a VM to native FTP under Windows XP. Here are the results: File size: 32MB Source: Linux 2.6.x running on a Pentium 233, local 100Mb/sec connection Windows XP command line FTP client: ~8950KB/sec LFTP running under Cygwin: ~8850KB/sec mTCP, VMWare 3.13, PCNet emulation, standard buffer sizes: ~3950KB/sec mTCP, VMWare 3.13, PCNet emulation, max buffer sizes: ~6826KB/sec So the maximum buffer size settings do improve performance quite a bit. I need to go back and test my older/slower machines to see if they see similar results. Performance characteristics have changed since I set those buffer sizes and some tweaking to the defaults might be appropriate. (All of this can be set from the configuration file today, so no new code is needed.) Mike -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
On 7/6/2011 6:02 PM, Bernd Blaauw wrote: ftp://ftp.xs4all.nl/pub/test/10mb.bin : 1) 2.0 to 2.5MByte/second ( around 20Mbit/s, 25Mbit ISP subscription) 2) N/A , WGET not working 3) 500Kbyte/second ( around 4Mbit/s) mTCP FTP compares poorly to the native stack and FireFox there, but FTP is working in a very limited environment: * The TCP/IP socket receive buffer is tiny compared to the native network stack * You are doing filesystem writes 8KB at a time * You have a small virtualization penalty * The packet interface wasn't designed for high performance; every incoming packet requires a hardware interrupt and two software interrupts But for older machines, it is more than adequate. I'll try a few tests here - I also test under VMware, VirtualBox, and DOSBox but I never thought to compare the performance to the native TCP/IP stack. Did you set the MTU size to 1500 in the configuration file? If you did not, that will dramatically improve the speed. Trying to get FTP.EXE working with WGET syntax is funny. Limitation: servername has // prepended to it which ftp.exe doesn't like. That funny URI syntax was grafted on. What exact URI are you using? Are you adding ftp://; or just // ? Bug: DHCP.EXE doesn't start on newline, ruining IPADDRESS parameter (my MTCP.CFG has PACKETINT 0x60 but lacked CR/LF somehow). Can you explain this in more detail? If you were missing a proper CR/LF at the end of a line then the C runtime would not have recognized the start of the next line, and that line would be effectively lost. This happens if you use an editor that doesn't use the CR/LF convention. (I often make this mistake when using VI under Cygwin.) I could recognize both CR/LF and LF in the parsing code to improve things when you are in a mixed environment. But all of the code that reads the configuration file would have to change too, not just DHCP. That really has the flavor of a user error. Request: * FTP accepting // in front of a servername * DHCP starting MTCP.CFG writes on a newline * DHCP: different errorlevels for various situations instead of errorlevel 1 on all errors? aka how to determine if packet driver still needs to be loaded Bernd For the first request I think that I have to look for either ftp://; or just // to be correct. The second request might be considered a user error. And for the third I will definitely put that on the todo list; the error messages already indicate if the packet driver is not loaded but I can set errorlevel too. Mike -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Thanks for the plugs for mTCP - I am buried in work and away from email for a good part of the day. There are a lot more WATTCP apps out there because WATTCP has been around a lot longer, and there is a benefit to that long term stability. I think that I have covered the more popular applications in mTCP so far, with the exception of htget or wget. If you can think of others let me know. Also, Ulrich has done a great job putting together a FreeDOS networking sampler (http://lazybrowndog.net/freedos/virtualbox/) for anybody who needs to try it out or look at configuration files for help. It includes WATTCP and mTCP apps. (mTCP has been updated a few times since that was created, but it is close enough.) Mike -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
On 7/2/2011 7:42 PM, Bernd Blaauw wrote: Op 3-7-2011 1:54, François Revol schreef: Any of those two supports IPv6 ? So FreeDOS can survive the IPcalypse :D Don't think so. Stuff I can think of which is missing: 1) WGET/CURL 2) WOL-client to wake up machines in the network by sending magic packet 3) IP v6 4) Jumboframes (9000 bytes I think it was?) as MTU As for the usual rhetoric: it's opensource, patches welcome, fix it yourself if you want more hehe :) Or wait till Michael has time and sees use in adding these things. As FTP.EXE is a DOS program, and DOS is singletasking anyway, I wonder if it uses as big a buffer as it can possibly get (for simplicity's sake, all available conventional memory, not bothering with XMS/EMS etc as it's a 8086 app) and use it in a beneficial way to speed things up. Or maybe it might be limited to a partial buffer, or not benefit from going over a specific buffer size. [1] A fully featured wget will be difficult to get into the memory space. I have plans for a simple version that does not recurse, does not support Unicode, etc. [2] WOL-client. Pretty easy, but seems to be of limited use. [3] IPv6 - this is very feasible. I started looking at it a few years ago but did not start coding because IPv6 is not widespread enough for me to test effectively. (I have my own network, but I'm waiting for broader ISP support.) With IPv6 we will survive the IPocalypse. :-) [ François - loved that! ] [4] Jumboframes - unlikely. That's a packet driver issue and none of the packet drivers support jumbo frames. I can change the maximum frame size fairly easily (it is a #define) but without packet driver support it is moot. (Some of the newer cards have packet drivers with source code available, so maybe it is not so bad.) There are other issues with jumbo frames. We might be able to support them, but getting the performance out of them will be close to impossible with the way packet drivers work. If you hardware can do jumbo frames it might be a better candidate for a small Linux. FTP uses buffer sizes around 8KB in size, and it is adjustable with an environment variable. 1KB was too small. 4KB was far better. 16 and 32KB give marginal improvements. I chose 8KB as a compromise. (Look at the docs for the environment variables.) Mike -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
