[Freedos-user] FreeDOS is 20 years old!
In a June 29, 1994 post https://groups.google.com/d/msg/comp.os.msdos.apps/oQmT4ETcSzU/O1HR8PE2u-EJ to USENET, we announced a public domain DOS which later became the FreeDOS Project: Announcing the first effort to produce a PD-DOS. I have written up a 'manifest' describing the goals of such a project and an outline of the work, as well as a 'task list' that shows exactly what needs to be written. I'll post those here, and let discussion follow… Since then, we have advanced what DOS could do, adding new functionality and making DOS easier to use. And in 2014, people continue to use FreeDOS to support embedded systems, run business software, and play classic DOS games! -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS is 20 years old!
Congratulations! Jim Hall schreef -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sudoku on a 8086 (or anything newer)
I'm surprised nobody's yet suggested ways to make a better version of Sudoku. What it is so far is a good start, but there could be a lot more done to it to make it better, for example: On-line help Better Manual Allow use of letter, colors, symbols, etc. instead of just numbers Different playability hardness levels Allow super-hints (partial/complete fill-in by the computer) The biggest thing missing, though, is some way to keep user notes in each square. As I'm doing a Sudoku puzzle on paper, I write and erase/cross-out numbers at the bottom of each square as I work through the puzzle paring down the (im)possibilities. There may be people who can just look at a Sudoku puzzle and figure it out, but I certainly can't. It is a long, involved logical elimination process, and I have to write down notes as I go along. If I'm unable to write notes in an electronic version, I won't use it. The computer could even do the notes automatically (at least the type of notes I use, which are simply the numbers for a box that can't yet be eliminated as possibilities). I've seen other people write their notes at the top of the box, and I've experimented a little with different solution methods that involve using all four sides of a box for notes (with different sides corresponding to different kinds of notes). Different people may use different methods, and an electronic version should enable the same kinds of things someone can do with a paper version. *** I must also say that having it only require an 8086 is the correct approach. Even though almost everything these days has at least a pentium class machine, a Sudoku game certainly doesn't need more resources than an 8086 can provide. While it's not chic these days, it's the correct approach, IMO. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sudoku on a 8086 (or anything newer)
Hi Bret, I see there are more Sudoku players on this mailing list than I expected :) Sure there could be lots of additional features (like in any software) - I was trying to focus on the most classic vision of Sudoku, and do it right, instead of going into hundreds of features that I wouldn't have the time to finish. Of course it's not impossible that I'll add some new bits in the future, but I can't promess anything. About hints: Yes, I totally agree that doing a Sudoku without being able to mark hints is a pain. But Sudoku86 *does* support hinting. Just use the right click of your mouse ;) Could be that the right click doesn't work for you. If that's the case, it's a bug, and I'd really like to know more about it. As I wrote in an earlier message, DOSEmu was buggy until yesterday, so if you test under DOSemu, it's 'normal' the right click doesn't work (try upgrading DOSemu from git, it's fixed by now). If you test on something else, please tell me what mouse you use (USB/PS2/Serial?) and what mouse driver, so I will see if I have any chance to reproduce the problem. About Playability hardness: instead of relying on the embedded levels, you could use any *.sdm collection of sudoku levels, and convert it to the Sudoku86 format using the tool 'sdm2lev' included in the archive. Anyway, please let me know about your 'right click' issue, I'm really curious. cheers, Mateusz On 06/30/2014 06:36 PM, Bret Johnson wrote: I'm surprised nobody's yet suggested ways to make a better version of Sudoku. What it is so far is a good start, but there could be a lot more done to it to make it better, for example: On-line help Better Manual Allow use of letter, colors, symbols, etc. instead of just numbers Different playability hardness levels Allow super-hints (partial/complete fill-in by the computer) The biggest thing missing, though, is some way to keep user notes in each square. As I'm doing a Sudoku puzzle on paper, I write and erase/cross-out numbers at the bottom of each square as I work through the puzzle paring down the (im)possibilities. There may be people who can just look at a Sudoku puzzle and figure it out, but I certainly can't. It is a long, involved logical elimination process, and I have to write down notes as I go along. If I'm unable to write notes in an electronic version, I won't use it. The computer could even do the notes automatically (at least the type of notes I use, which are simply the numbers for a box that can't yet be eliminated as possibilities). I've seen other people write their notes at the top of the box, and I've experimented a little with different solution methods that involve using all four sides of a box for notes (with different sides corresponding to different kinds of notes). Different people may use different methods, and an electronic version should enable the same kinds of things someone can do with a paper version. *** I must also say that having it only require an 8086 is the correct approach. Even though almost everything these days has at least a pentium class machine, a Sudoku game certainly doesn't need more resources than an 8086 can provide. While it's not chic these days, it's the correct approach, IMO. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMODE - translation from Pascal to C - solved
On 06/29/2014 11:19 AM, dmccunney wrote: On Sat, Jun 28, 2014 at 8:35 PM, Zbigniew zbigniew2...@gmail.com wrote: It was always a bit strange to me, that I had - well, I still have ;) - a few quite useful Pascal compilers for such little machine, like Commodore 64, and just one C compiler (Power C), which is cumbersome and hard to work with. C compiler - for the language being closer to machine than Pascal or BASIC - theoretically should be less resource-hungry (just like Forth compilers). There are fundamental language differences to take into account. Niklaus Wirth created Pascal as a teaching tool, for teaching algorithm design. It was originally intended to be compiled on paper, with the teacher grading the quality of the student's assignment. In ISO standard Pascal, the last I knew, things like I/O were undefined, because a program wouldn't *do* I/O. When compiler writers began creating compilers to generate executables from Pascal code, they had to roll their own in areas like I/O, because it wasn't defined in the language. Pascal spread widely be4cause it was relatively easy to learn to write, but became inherently non-portable because of differences in implementations. The C language was created by Dennis Ritchie at Bell Labs, largely concurrently with the development of Unix by Ken Thompson and Brian Kernighan. C was intended to solve a specific problem. Up till C came about, systems software, like operating systems, was written in the flavor of Assembler supported on the target machine. The DEC minicomputers used to host the development of C and Unix, for example, used Macro-11, DEC's flavor of Assembler. (DEC also had a specialized language called BLISS intended for systems software.) The problem with Assembler was that while it provided the greatest possible efficiency, it was hard to write and harder to maintain. The developer had to think with the machine's point of view, which was very different from the problem to be solved. Ritchie was creating a language intended to have the control constructs available in higher level languages, but efficient enough that you didn't *have* to write in Assembler to get adequate performance. Another goal was that it be portable, and relatively easy to bring up on a different machine. He wanted a language to make it easier and faster to write operating systems. Unix was intended to solve a similar problem. Thompson and co-workers were software developers, unhappy with the facilities provided by the DEC systems on which they worked to support the task of software development. The had an old DEC mini that was essentially unused, and could start from scratch, creating a new OS better suited for developing software. Early versions of Unix were written in Macro-11. Around Unix v6, C became mature enough to be used, and most of Unix was rewritten in C. Only really low level code that interfaced with the hardware was coded in Assembler. The portability of C made it possible to bring up Unix on systems that weren't DEC minis, and it began to spread throughout ATT. (An early driver of the spread was being able to use the vi screen editor when writing patent applications, instead of the line editors available up till then.) The earliest C compiler used in Unix compiled the C language statements into Assembler, and then called as, the system assembler, to generate the object code from the Assembler, and ld, the link editor, to put the parts together into an executable the user could run. It was possible to interrupt the compilation before as was called, and hand optimize the Assembler code before continuing. It was rather later that C compilers became sophisticated enough to comple directly to object code. Those early DEC minis had a 32K address space, so C had to be compiled in a low resource environment. But generating the *smallest* executable wasn't the main goal. There is always a tradeoff between speed and code size. The fastest possible code is in line, but the more code that is in line, the larger the object file will be. To make code small, you isolate code that will be executed multiple times as a function, and you call the function, but calling the function has overhead and your code isn't as fast. In addition, C encouraged the development of libraries, where functions used in many programs could be stored for reuse, and you passed the compiler a parameter telling it where to look for libraries used by your program. When you compiled your code, and a function was encountered that was not in the code you wrote, the linker would search the libraries passed for the code than implemented that function, and include it in the executable. Doing all that took resources, The compiler had to have a temporary file where the compiled output was stored, buffers in memory to hold the code being compiled, and tables in memory to store information about the code being
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
Hi, On Sun, Jun 29, 2014 at 7:05 PM, Zbigniew zbigniew2...@gmail.com wrote: No, no such exotic options, Well, I would maybe recommend I=TEST X=TEST. and using JEMM386 didn't help Again, I think it's better to LOAD and UNLOAD from cmdline (JEMM386) when needed to avoid such problems. - but I located the problem: JEMMEX isn't to blame. Somehow TC's IDE doesn't like 4DOS - when switched to FREECOM, the problem is gone. IIRC, 4DOS can swap out (since it's quite large) to conserve conventional memory. You may have to change that setting (SWAPPING ?? I forget ...). I don't think it's something inherently wrong with 4DOS, but who knows. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
2014-06-30 19:19 GMT+02:00, Rugxulo rugx...@gmail.com: Hi, On Sun, Jun 29, 2014 at 7:05 PM, Zbigniew zbigniew2...@gmail.com wrote: No, no such exotic options, Well, I would maybe recommend I=TEST X=TEST. I used - and still use - exactly the two above. IIRC, 4DOS can swap out (since it's quite large) to conserve conventional memory. You may have to change that setting (SWAPPING ?? I forget ...). I don't think it's something inherently wrong with 4DOS, but who knows. But I already wrote, that when using JEMMEX and 4DOS I had more memory available (both conventional upper), than using XMGR + FREECOM? And - despite of this - that only in latter case I could switch to shell from TC's IDE? -- Z. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sudoku on a 8086 (or anything newer)
Hi, On Mon, Jun 30, 2014 at 11:54 AM, Mateusz Viste mate...@viste.fr wrote: Sure there could be lots of additional features (like in any software) - I was trying to focus on the most classic vision of Sudoku, and do it right, instead of going into hundreds of features that I wouldn't have the time to finish. Of course it's not impossible that I'll add some new bits in the future, but I can't promess anything. Standard disclaimer: Patches welcome! :-) Could be that the right click doesn't work for you. If that's the case, it's a bug, and I'd really like to know more about it. In addition to my desktop (Lenovo), I tried on my laptop as well (Dell). Same CuteMouse version (latest, 2.1b4). Same problem. (I assume that rules out a BIOS bug.) Right click will erase, but if it's already empty, it only temporarily flashes the number (full size). Which is of course not what DOSBox does. About Playability hardness: instead of relying on the embedded levels, you could use any *.sdm collection of sudoku levels, and convert it to the Sudoku86 format using the tool 'sdm2lev' included in the archive. Sudoku supposedly originated in Japan, where it's very popular. I've heard that some people pride themselves on hand-crafting each puzzle. And of course the difficulty can vary quite a bit. Even our local newspaper a few years ago started to include them every day (well, before they went with the three-days-a-week abomination, I haven't checked lately), from easy (Monday) to difficult (Friday). Part of the appeal of aidan.c (from IOCCC '05) was generator and solver in one. (And of course portability, even to lonely ol' DOS.) But he lamented that you couldn't choose difficulty at generation time. I've not tried thousands of puzzles, but the single rule seems to be that it must have one and only one solution. I've heard that some require you to literally guess (temporarily) instead of pure elimination. That seems a bit too much! I don't like that at all. BTW, my favorite text editor (which I've been using for years) is TDE, and it has a Sudoku expansion pack. I only tried it like once, though. (5.2 still isn't finalized. He said at one point that Sudoku fans will be happy, but I can't remember why.) I wish I could point to his website to show you, but it never loads for me. He always seems to pick the weirdest web hosts, which don't work (oddly). http://tde.adoxa.vze.com/(from .LSM online) ... just redirects to ... http://adoxa.altervista.org/tde/ So it actually loads now! I'm surprised. Anyways, here's what it says (just FYI): Sudoku (21k): files to use TDE to play a game of Sudoku. More puzzles (52k) Anyway, please let me know about your 'right click' issue, I'm really curious. Naive guess: probably just some accidental residue, some register value left unchecked or unrestored that DOSBox is somehow masking. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
On Mon, Jun 30, 2014 at 1:30 PM, Zbigniew zbigniew2...@gmail.com wrote: 2014-06-30 19:19 GMT+02:00, Rugxulo rugx...@gmail.com: IIRC, 4DOS can swap out (since it's quite large) to conserve conventional memory. You may have to change that setting (SWAPPING ?? I forget ...). I don't think it's something inherently wrong with 4DOS, but who knows. But I already wrote, that when using JEMMEX and 4DOS I had more memory available (both conventional upper), than using XMGR + FREECOM? And - despite of this - that only in latter case I could switch to shell from TC's IDE? I've encountered that in other contexts. 4DOS works essentially the same way a COMMAND.COM. There is a resident portion and a transient portion. When you load the shell, the resident portion is relocated to the top of available memory. When you run a program from the shell, the transient portion is overwritten by your program to give it more conventional memory. When you exit the program, the transient portion is reloaded, using the SHELL= line to specify what to reload from and where to find it. (If you use a stock system with COMMAND.COM, you don't need the SHELL= line, because DOS will reload from \COMMAND.COM on your boot drive.) The transient portion of 4DOS is much larger than than that of COMMAND.COM. 4DOS will let you swap most of itself EMS, XMS, or disk, depending on what you specified in the SWAPPING config, to leave more room in conventional RAM. The problem is what happens when you shell to DOS from within an application. You are attempting to load COMMAND.COM or 4DOS in the conventional memory left over by the application you shelled from. If your application takes enough conventional memory, 4DOS will fail to load because there isn't enough room left for its transient portion, but COMMAND.COM will work because it will fit. I tend to invoke such applications from a batch file that sets SHELL to point to COMMAND.COM instead of 4DOS, and invoke the app by command /c app to start it from COMMAND.COM. Z. __ Dennis -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
Hi, On Mon, Jun 30, 2014 at 12:30 PM, Zbigniew zbigniew2...@gmail.com wrote: 2014-06-30 19:19 GMT+02:00, Rugxulo rugx...@gmail.com: IIRC, 4DOS can swap out (since it's quite large) to conserve conventional memory. You may have to change that setting (SWAPPING ?? I forget ...). I don't think it's something inherently wrong with 4DOS, but who knows. But I already wrote, that when using JEMMEX and 4DOS I had more memory available (both conventional upper), than using XMGR + FREECOM? But not by much. Sorry, but 599 vs 609 kb isn't really worth worrying about, IMHO. Of course, the extra 14 kb UMB is more significant (barely), but have you tried UMBPCI? Then you don't need EMM386 at all. http://www.uwe-sieber.de/umbpci_e.html For me, I just use XMS only, and it's good enough. (I encountered a few rare incompatibilities with EMM386, esp. NOVCPI, so I don't load any of that by default anymore.) I put all the unloadable stuff at the end of my AUTOEXEC, so if I need the RAM, I can reclaim it manually instead of rebooting. I can't remember all of them, but at least NNANSI, CTMOUSE, SHCDX33F can unload. (Okay, BIOS emulation bugs make CTMOUSE almost unusable for me when physically connected via USB instead of PS/2. Not that I prefer the mouse for anything anyways. So these days it's disabled by default.) And - despite of this - that only in latter case I could switch to shell from TC's IDE? No idea, I'm not a heavy user of TC201's IDE. But I'm still not sure I'd blame 4DOS entirely (if at all). Keep fiddling with it, try to see if you can isolate (or avoid) the problem without switching shells entirely. Actually, maybe the IDE is checking COMSPEC and you're not loading that properly? Or maybe it expects hardcoded COMMAND.COM or even C:\COMMAND.COM? Maybe if you renamed 4DOS.COM (locally) to C:\4DOS\COMMAND.COM and tried that?? BTW, does this mean you tried JEMMEX + FreeCOM as well? Results? -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sudoku on a 8086 (or anything newer)
On Mon, Jun 30, 2014 at 1:50 PM, Rugxulo rugx...@gmail.com wrote: BTW, my favorite text editor (which I've been using for years) is TDE, and it has a Sudoku expansion pack. I only tried it like once, though. (5.2 still isn't finalized. He said at one point that Sudoku fans will be happy, but I can't remember why.) I wish I could point to his website to show you, but it never loads for me. He always seems to pick the weirdest web hosts, which don't work (oddly). http://tde.adoxa.vze.com/(from .LSM online) ... just redirects to ... http://adoxa.altervista.org/tde/ So it actually loads now! I'm surprised. Jason lives in Australia. He looks for free web hosts that offer sufficient bandwidth to handle the (low) traffic, and enough disk space to host his code. (Enough disk space is the sticky part.) I've never had a problem connecting to any of his various hosts. but I'm in NYC with good connectivity. You may be in a area with issues. According to a Firefox extension, the Altervista server is actually located in Germany, run by Hetzner Online AG, and is at 5.9.157.106 __ Dennis https://plus.google.com/u/0/105128793974319004519 -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sudoku on a 8086 (or anything newer)
This mouse issue is really bothering me, as I have no much clue what's going wrong... On 06/30/2014 07:50 PM, Rugxulo wrote: Right click will erase, but if it's already empty, it only temporarily flashes the number (full size). This sounds very much like you (or your mouse) would click twice - I mean, imagine that when you right click, what your mouse (or driver, or BIOS, or I don't know what) actually do is (very fast): - LEFT click - RIGHT click This would generate exactly the symptoms you have, including the 'fast flashing' of the big number. I know this is a far-fetched idea, but you never know... (and I don't have any better idea at hand). I created a little (4K) test program for the mouse. Could you please use it on your hardware and tell me what you see? http://www.viste-family.net/mateusz/temp/moustest/ The program will simply wait for clicks, and print them on the screen. So the whole point would be for you to click with the mouse using left / right clicks, and confirm that for every click you obtain exactly 1 and only 1 new message on the screen. If you obtain any other behavior, then it would be really cool if you could write down the exact messages (ie. the AX and BX values that the program will display). Naive guess: probably just some accidental residue, some register value left unchecked or unrestored that DOSBox is somehow masking. This would fit of course, if I had tested only on DOSBox.. But I do test also on a real PC, with a real mouse on a real PS/2 port (and ctmouse 2.1b4), and I don't have the problem you describe. ciao, Mateusz -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sudoku on a 8086 (or anything newer)
What you call hints is what I call notes. To me, hints are something the computer generates smartly when you ask it, and notes are something I provide myself and the computer just helps me keep track of them. It does do notes. Notes do work with the right mouse button -- I didn't notice that before, though I did figure out that the right button is a remove. Nomenclature again, but what others seem to call an undo is what I would call remove. An undo is where the computer undoes the last thing you did, whatever or wherever it was. You definitely need at least minimal documentation on what the mouse buttons are supposed to do in different situations (at least on screen when you're playing the game), and the fact that everything on the keyboard except Escape is useless. Adding keyboard support would be nice, also. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Sudoku on a 8086 (or anything newer)
On 06/30/2014 10:15 PM, Bret Johnson wrote: What you call hints is what I call notes. To me, hints are something the computer generates smartly when you ask it, and notes are something I provide myself and the computer just helps me keep track of them. Put that way, your definitions are clear - and indeed, Sudoku86 definitely do 'notes', not 'hints'. Notes do work with the right mouse button This is actually great news for me - I was starting to fear that the odd problem Rugxulo is experiencing is somehow common to everyone besides me. I'm glad then it all works as expected for you. Nomenclature again, but what others seem to call an undo is what I would call remove. Yes, I agree the 'undo' name is ambiguous here. The reason I call the Sudoku86 behavior an 'undo' is because it will restore the 'notes' you made on the field before writing a number into it. You definitely need at least minimal documentation on what the mouse buttons are supposed to do in different situations (at least on screen when you're playing the game), and the fact that everything on the keyboard except Escape is useless. Adding keyboard support would be nice, also. Now I see it. I was sure that the mouse interface is super-intuitive, but of course I was highly subjective in this thinking, and now it's obvious that it needs to be explained with some actual words in the documentation and possibly in the game itself. Thank you for your feedback! Mateusz -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMODE - translation from Pascal to C - solved
Hi, On Sun, Jun 29, 2014 at 4:11 PM, dmccunney dennis.mccun...@gmail.com wrote: On Sun, Jun 29, 2014 at 4:21 PM, Rugxulo rugx...@gmail.com wrote: On Sun, Jun 29, 2014 at 1:19 PM, dmccunney dennis.mccun...@gmail.com wrote: I think you're mistaking it for ALGOL 60. Because Pascal always had I/O built-in to the language (and compiler). That part was always there, even before ISO got involved. Not in Wirth's original design for the language, it wasn't. As stated, it was intended to be a teaching tool, and there was no assumption of Wirth's part that it would actually be implemented on a machine. While I'm no true historian and admittedly only know bits and pieces, that doesn't sound right at all. Are you going off of memory or can you cite specific people or books to verify this? (It doesn't matter much, obviously. I could maybe email Scott Moore since he knows more than almost anybody.) AFAIK, Pascal was designed and almost immediately implemented on real hardware and soon used in teaching students (mathematicians, physicists, etc) at ETH Zurich circa 1970 or 1971. It's still considered part of the ALGOL descendant line because of stylistic similarities and Wirth's history, esp. with his previous language ALGOL W. And even ALGOL W was physically implemented at Stanford with Wirth's help, and he did work at Stanford from 1963-7 (according to Wikipedia). I don't know how to go back in time to 1970 to find out for sure. (And it really doesn't matter much anyways.) But I do have a PDF copy of the 1973 Report (which admits a few very minor changes in the Pascal language itself due to experience). http://sourceforge.net/p/pascalp5/code/ci/master/tree/The_Programming_Language_Pascal_1973.pdf The very first paragraph of that report mentions Algol 60, teaching programming, and efficient tool to write large programs, as well as efficient implementability and an existing one-pass compiler ... CDC 6000. This was no abstract toy. However, in fairness, it does seem to mention read and write as being standard procedures, described in a new Chapter 13. So maybe it really was a new 1973 feature (unlikely, IMHO, considering that it compiled itself and was strict on static typing and error checking) or at least just a new addition to the manual. If you read chapter 13, you'll see that it says read(c) is the same as c := input^; get(input) and write(c) is the same as output^ := c; put(output). But it's not wrong to say that he meant it to be explainable without a computer. People like Dijkstra advocated that for ages. But they had a CDC mainframe at ETH Z, so it's not like students couldn't send off their programs and receive back the output (or errors). Later, Wirth wrote Pascal-S (subset) interpreter to speed up turnaround time even more. Obviously the formalism of strictly defining the language grammar came from ALGOL (and Wirth more or less popularized EBNF, railroad diagrams, T squares or whatever, compiler construction, etc). Pascal also suffered from lack of standards. There were lots of Pascal implementations, all different in various ways. You could not expect to write Pascal code that would build an run, for example, on a PC under Turbo Pascal, and a DEC VAX under DEC Pascal. Not counting Pascal-S (strict subset interpreter), the only other subsets were the various P[1234] porting tools. It's been said that P2 was incomplete but still used (if not literally, at least as inspiration) by UCSD Pascal (and later Borland). Even P4 (the last of the series, circa mid '70s) was incomplete. This was way before any of the various standardization efforts. It was not full Pascal, in contrast to the CDC version. (Scott Moore only in recent years added in the rest of ISO 7185 to what he calls P5.) BTW, standard unextended Pascal is almost exactly the same as JW. No new features were added. AFAIK, not counting semi-official JW, work towards a standard first started circa 1977, and BSI was the original group to push for one. There were also (later) ANSI/IEEE and ISO. Depending on which version (of what is basically the same thing, classic / unextended), the finalization year was something like 1981 or 1983. The later (also unpopular) Extended Pascal standard came in 1988 or such (and had far less compilers developed, and obviously Wirth had moved on to greener pastures). The official BSI test suite is nowadays abandoned, locked up, thrown away. (Sadly, though luckily Scott Moore has his own public test suite.) Most of it came from PUG (Pascal User Group) newsletters, I think. But that was the official way that people tested their implementation. (See (T)ACK.) Or were supposed to, anyways. For whatever reason, many implementations either were buggy or incomplete or just didn't care (ahem, Borland). That doesn't mean it was impossible, just that the effort was lacking. (BTW, you can't standardize that which keeps changing. But the reason people hate standards is that they're too weak or too baroque. Yet
