Re: [Freedos-user] Mpxplay won't be developed in the future...
> Any non Windows applications, better said any pure DOS legacy > application should work on FreeDOS the same way it would work on MS-DOS? > (this test on same hardware of course) right. we (the kernel and emm386/himem developers) put a lot of effort into exactly this. after that, we declared the work 'done' and left the rest as an exercise to the reader ;) Tom - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Thanks for detailed answer. So... If I understand right. Most things are in but some cool addons are still missing. Any non Windows applications, better said any pure DOS legacy application should work on FreeDOS the same way it would work on MS-DOS? (this test on same hardware of course) -mr - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Hi! > By the way which features are missing in FreeDOS > a) for 100 % MS-DOS compatibility Missing features in the stable kernel are: - country sys / nlsfunc support: present in unstable branch, would be nice if that could be ported to stable but WITHOUT breaking the compiled-in support for common countries there - possibly some int 2f.12nn functions?? I think many of them are already implemented, but int 2f in general has lots of odd functions and somebody would have to read RBIL and our source code to check which of them are not yet implemented. - config sys menu: only syntactic incompatibility, as with some other "incompatible" apps (I assume you only ask about kernel, but for we have no app with the look and feel of MSAV... ;-)) I think Arkady had plans about that but some developers were concerned about related changes in user interface...? - long file names: not part of classical MS DOS 5/6, but part of bundled-with-Windows-9x MS DOS 7, available via DOSLFN :-) - instances, critical sections and full "reentrancy as long as you swap the SDA contents": only used by Windows 3.x and by Windows for Workgroups 3.11 (for 386Enh "multitasking" mode)? See below! - int 21.4b05 set execution state: unknown what this does, what needs this and how it can be implemented...?? - support for file sizes between 2 and 4 GB: depends on having good documentation about how seek / read / write behaves here, is controlled (in part?) by setting a flag when opening files. Only makes sense on FAT32 and only if you know any app which would do anything useful with such big files... - support for file sizes above 4 GB: this is not supported in MS DOS but we could go compatible to a hack used in EDR DOS (normal directory entries only have 32 bit file size fields) - open files in SYNC and NOCRIT mode: this would trigger writing all changes to disk (bypassing BUFFERS but not external cache?) at once for SYNC, and would bypass critical error handler calls for NOCRIT (would just return error status instead). I wonder whether any known app uses this. SHARE might be non-perfect, too. - support for DBCS (wide chars) and Japanese / Chinese / Korean language: Only available in far east versions of MS DOS either, provides interfaces for communicating with wide char screen and keyboard drivers which were separately available?? - several int 21.5dnn functions: get a list of all open files and commit or close files by name / by owner PSP segment / by PC name (the latter is "in the network" but has defaults for offline case) Sort of useful but I wonder which apps actually use this :-). > b) for 3.11 compatibility Windows for Workgroups has a pretty useless "standard mode", so what you are looking for is not only WfW 3.11 compatibility but rather general Windows 386Enh mode compatibility. This requires Windows to be able to freeze and restore the kernel state to be able to run multiple instances of the kernel or make the kernel "reentrant". Note that Windows will try to do disk access without kernel help by default, which you should disable if you have LBA or FAT32 ;-). You also have to trick Windows into seeing at most 256 MB (with tweaks 1 GB) RAM, otherwise the internal memory mgmt of Windows 3 will overflow. Oh and segments larger than 16 MB have issues too, so you may have to add workarounds to HIMEM and other apps...? In any case: The unstable kernel branch has an experimental patch (available as the winkernel binary on FreeDOS 1.0) which attempts to give Windows all critical sections, instance data and swappable (SDA) kernel stuff it needs to run in FreeDOS. Give it a try ;-). As far as I remember, this involved heavy changes to fnode handling as f_nodes are not known to MS DOS and not swapped by Windows. Any attempt to port this to the stable kernel would need very careful review of the involved patches... > c) for 95/98/ME compatibility? Good question. Does anybody here know? Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Eric Auer schrieb: > Hi! > ... 95/98 on top. > >>> Why? Windows 9x always comes with underlying MS-DOS 7.x. >>> There's just no need for FreeDOS here. > > Note that this is how MS pushed DR DOS and PC DOS (etc) out > of the market - they made it alternatives obsolete by bundling > their own stuff. Now if you look at web browsers, media players > or office software, there it does make sense to install better > versions in spite of the "why should I MS already includes it > in Windows" factor. But for MS DOS 7 in Windows 98? Not really. > You would hardly notice any difference from replacing MS DOS 7 > (as long as you stay inside Windows 98, that is!). > >> - It's cool. > > Shrug... > >> - You can start and exit Windows and back to FreeDOS and back >> to other Windows version, pretty practical. > > That is what a boot menu is for, at slightly worse speed > but significantly better stability ;-) > >> - A good prof to become 100 % compatible to any software. > > The only software which needs cool "it is so compatible that > you can even use it to boot Windows 98" is actually Windows 98 > itself, so this coolness does not give you anything else... > > I mean Windows 98 does not even RUN in MS DOS 7, it only has > MS DOS 7 as a boot loader. Pretty large effort for replacing > a boot loader by rewriting 1000% MS DOS 7 if you ask me ;-). > > Nevertheless, MS DOS 7 is nice even without Windows so it is > still good that we support _some_ MS DOS 7 features here :-). > > Eric > Hi! :) By the way which features are missing in FreeDOS a) for 100 % MS-DOS compatibility b) for 3.11 compatibility c) for 95/98/ME compatibility? -mr - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Hi! > >> ... 95/98 on top. > > Why? Windows 9x always comes with underlying MS-DOS 7.x. > > There's just no need for FreeDOS here. Note that this is how MS pushed DR DOS and PC DOS (etc) out of the market - they made it alternatives obsolete by bundling their own stuff. Now if you look at web browsers, media players or office software, there it does make sense to install better versions in spite of the "why should I MS already includes it in Windows" factor. But for MS DOS 7 in Windows 98? Not really. You would hardly notice any difference from replacing MS DOS 7 (as long as you stay inside Windows 98, that is!). > - It's cool. Shrug... > - You can start and exit Windows and back to FreeDOS and back > to other Windows version, pretty practical. That is what a boot menu is for, at slightly worse speed but significantly better stability ;-) > - A good prof to become 100 % compatible to any software. The only software which needs cool "it is so compatible that you can even use it to boot Windows 98" is actually Windows 98 itself, so this coolness does not give you anything else... I mean Windows 98 does not even RUN in MS DOS 7, it only has MS DOS 7 as a boot loader. Pretty large effort for replacing a boot loader by rewriting 1000% MS DOS 7 if you ask me ;-). Nevertheless, MS DOS 7 is nice even without Windows so it is still good that we support _some_ MS DOS 7 features here :-). Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Robert Riebisch schrieb: > Michael Reichenbach wrote: > >> ... 95/98 on top. > > Why? Windows 9x always comes with underlying MS-DOS 7.x. There's just no > need for FreeDOS here. - It's cool. - You can start and exit Windows and back to FreeDOS and back to other Windows version, pretty practical. - A good prof to become 100 % compatible to any software. -mr - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Michael Reichenbach wrote: > ... 95/98 on top. Why? Windows 9x always comes with underlying MS-DOS 7.x. There's just no need for FreeDOS here. Robert Riebisch -- BTTR Software http://www.bttr-software.de/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
someone schrieb: > Open source > software is not as author dependent as traditional commercial software, > but a lot of people fail to understand this and they give up on an OSS > project when it's author quits. It's very hard to learn programming for hobbyists and professionals can rather earn money with programming something better. Plus the reasons it's often more easy to write new code then understanding old code, specially from other people. someone schrieb: > I guess one route is to encourage the developer of mpxplay to port > it to freedos32, if that is reaching beta stage yet. freedos32 is dead. >> mind. Freedos 1.1 needs a 32 bit gui that people are willing to >> write graphical programs for which need more than 640k. If the >> gui supports Windows 9x software, that'd be a great bonus. First FreeDOS should be become 100 % compatible with MS-DOS. Later the ability to run Windows 3.x/95/98 on top. If any DOS programmer wants to access more memory then 640k then he can either use EMS or XMS. An even better method would be to use DOS extenders. HX DOS Extender is pretty good and actively maintained, using DPMI you can access all memory outside conventional/EMS/XMS. It's also pretty easy to develop with. (from what I see no special way of requesting memory needed, just normal style) -mr - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Sounds like port WINE to DOS :-) -- +-+-+-+-+-+-+-+ Marco A. Achury www.geocities.com/marcoachury - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Quoting Eric Auer <[EMAIL PROTECTED]>: > > Hi Michael, > >> Well, ReactOS is an NT clone. Freewin95 was the >> original project that later became ReactOS when... > > Hmmm. > >> Why? The facts are not encouraging as far as the time it took >> for ReactOS 0.3.5 to be released and 0.3.5 is an alpha. > > Things count in different ways in open source, projects > are often very humble about version numbers. I mean nobody > used Win 1 or 2 for anything, let alone Windows beta 0.x ;-) > >> I guess one route is to encourage the developer of mpxplay to port >> it to freedos32, if that is reaching beta stage yet... > > Any reason why it would be better than mpxplay for normal DOS? > >> route is to implement a 32 bit version of opengem that will run on >> top of freedos 1.1. It sounds like the developer is concerned that >> it is easier to write a Windows program than it is to write for any >> of the dos based extenders. Well, a better gui might change... > > Maybe he wants to try SDL, or maybe (hint hint) make the Windows > version simple enough to let it work in DOS with HXRT ;-). > >> mind. Freedos 1.1 needs a 32 bit gui that people are willing to >> write graphical programs for which need more than 640k. If the >> gui supports Windows 9x software, that'd be a great bonus. > > Then it would be FreeWindows98, not FreeDOS. Totally different. > And every GUI can only be popular if there are lots of apps. > I mean even if you write FreeWindows3 today, people would say > that there is not enough software for it. OS2 and GEM are in > even worse position. > >> I've heard that there are various attempts to develop gui's other >> than opengem for dos and I've even run into claims that freedos >> will eventually compete with Linux and Windows. Well, I think >> freedos has a place on older computers that are powerful enough >> to be useful if the OS is light enough. Windows 9x is a mess, >> this is partially why dos went away. I have yet to see an NT >> style system be as light as dos. ReactOS is promising, but it's >> potential is a year or two down the road still. ReactOS will get >> better, but it will be an NT clone instead of a Win 9x replacement. > > Okay so you want a Windows NT clone which runs on hardware which > is too old for Windows 98...? And you hope DOS is that system... > I am sorry - but things do not work that way. If you write NT for > DOS then it will have almost all the disadvantages of NT combined > with many limitations of DOS. It will not have the advantages > of NT combined with the lightness of DOS... > >> One advantage of a strong 32 bit gui that runs on top of dos, >> it becomes possible to port firefox 3 to freedos. > > Firefox runs totally great on Linux... Given that the Fire fox > instance which is on my screen right now uses 300 MB of RAM > (half of which swappable) running in X.org which uses another > 150 MB of RAM (...) I would say it makes little sense to run > either of the two (you need X to run Firefox) on DOS for the > sake of "DOS only uses 1 MB" ;-)) > > Eric Windows 98 is NOT Windows NT. It is a version of Windows that runs on top of dos. Linux uses more memory because it is a multi user system with an overkill gui. Freedos 32 shouldn't in theory doesn't need dos extenders as it already runs in protected mode and it offers a flat memory model. I am not proposing Windows NT Lite, I am proposing a windows compatible gui that runs on top of dos minus some of the features that would make it really really heavy. Michael C. Robinson This message was sent using IMP, the Internet Messaging Program. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Hi Michael, > Well, ReactOS is an NT clone. Freewin95 was the > original project that later became ReactOS when... Hmmm. > Why? The facts are not encouraging as far as the time it took > for ReactOS 0.3.5 to be released and 0.3.5 is an alpha. Things count in different ways in open source, projects are often very humble about version numbers. I mean nobody used Win 1 or 2 for anything, let alone Windows beta 0.x ;-) > I guess one route is to encourage the developer of mpxplay to port > it to freedos32, if that is reaching beta stage yet... Any reason why it would be better than mpxplay for normal DOS? > route is to implement a 32 bit version of opengem that will run on > top of freedos 1.1. It sounds like the developer is concerned that > it is easier to write a Windows program than it is to write for any > of the dos based extenders. Well, a better gui might change... Maybe he wants to try SDL, or maybe (hint hint) make the Windows version simple enough to let it work in DOS with HXRT ;-). > mind. Freedos 1.1 needs a 32 bit gui that people are willing to > write graphical programs for which need more than 640k. If the > gui supports Windows 9x software, that'd be a great bonus. Then it would be FreeWindows98, not FreeDOS. Totally different. And every GUI can only be popular if there are lots of apps. I mean even if you write FreeWindows3 today, people would say that there is not enough software for it. OS2 and GEM are in even worse position. > I've heard that there are various attempts to develop gui's other > than opengem for dos and I've even run into claims that freedos > will eventually compete with Linux and Windows. Well, I think > freedos has a place on older computers that are powerful enough > to be useful if the OS is light enough. Windows 9x is a mess, > this is partially why dos went away. I have yet to see an NT > style system be as light as dos. ReactOS is promising, but it's > potential is a year or two down the road still. ReactOS will get > better, but it will be an NT clone instead of a Win 9x replacement. Okay so you want a Windows NT clone which runs on hardware which is too old for Windows 98...? And you hope DOS is that system... I am sorry - but things do not work that way. If you write NT for DOS then it will have almost all the disadvantages of NT combined with many limitations of DOS. It will not have the advantages of NT combined with the lightness of DOS... > One advantage of a strong 32 bit gui that runs on top of dos, > it becomes possible to port firefox 3 to freedos. Firefox runs totally great on Linux... Given that the Firefox instance which is on my screen right now uses 300 MB of RAM (half of which swappable) running in X.org which uses another 150 MB of RAM (...) I would say it makes little sense to run either of the two (you need X to run Firefox) on DOS for the sake of "DOS only uses 1 MB" ;-)) Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
ReactOS might support Windows 98 programs... Well, ReactOS is an NT clone. Freewin95 was the original project that later became ReactOS when progress was too slow. The developers, according to the bulletin boards, have given up on dos based Windows. That is too pessimistic, years for ReactOS to get stabilized. Why? The facts are not encouraging as far as the time it took for ReactOS 0.3.5 to be released and 0.3.5 is an alpha. Alpha means, if it works at all that is great. The 0.5.x series will be the first beta series. It is supposed to come out this year, but the next release is 0.3.6 and the 0.4.x series hasn't even happened yet. Anyone who expects an alpha to support the software they are interested in using is crazy. I haven't given up on ReactOS, I just realize that it will be a year before it reaches beta, and that is optimistic. Keeping mpxplayer for dos alive... I guess one route is to encourage the developer of mpxplay to port it to freedos32, if that is reaching beta stage yet. Another route is to implement a 32 bit version of opengem that will run on top of freedos 1.1. It sounds like the developer is concerned that it is easier to write a Windows program than it is to write for any of the dos based extenders. Well, a better gui might change his mind. Freedos 1.1 needs a 32 bit gui that people are willing to write graphical programs for which need more than 640k. If the gui supports Windows 9x software, that'd be a great bonus. I've heard that there are various attempts to develop gui's other than opengem for dos and I've even run into claims that freedos will eventually compete with Linux and Windows. Well, I think freedos has a place on older computers that are powerful enough to be useful if the OS is light enough. Windows 9x is a mess, this is partially why dos went away. I have yet to see an NT style system be as light as dos. ReactOS is promising, but it's potential is a year or two down the road still. ReactOS will get better, but it will be an NT clone instead of a Win 9x replacement. One advantage of a strong 32 bit gui that runs on top of dos, it becomes possible to port firefox 3 to freedos. Michael C. Robinson This message was sent using IMP, the Internet Messaging Program. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Hi Michael! > > My personal opinion here is that MPXPLAY is very nice for DOS > > users because it supports many soundcards :-). The ability to Note: The drivers are inside MPXPLAY, but as it is open source, you can use the MPXPLAY sources to make VSB (virtual sound blaster) able to output sound using, for example, your AC97 soundcard :-). The standard (1995) version of VSB can only use the internal PC speaker / beeper or covox (D/A converter connected to the printer port) so more hardware drivers are certainly a good idea for it. > > use network and video would not be a main issue for me. Maybe > > Attila can continue updating the sound drivers for DOS while > > focusing on Windows for the video support? > Depending on the licensing scheme for mpxplay, someone else can > continue developing the dos version. The sad thing about developing Of course. Depends... I assume Attila has lots of experience here. Are his sources well documented? We could ask him to write a driver writing howto :-). But who knows, maybe he will even continue to make new DOS drivers for MPXPLAY in the future if enough people keep using MPXPLAY in DOS and showing their appreciation :-). > a Windows version is that ReactOS, the only free Windows clone I know > about, is years away from being something that is usable. There just > aren't enough developers. Windows 9x is something better than a dos That is pessimistic about ReactOS. It did not look that bad, but their project has large plans while having few developers. If it supports running Win98 apps, you could ask them to improve the Win98 support - I guess that would be easier than completing the Win2000 support... > extender, but noone wants to develop a free replacement for that. You could try Japheth's HXRT, which is pretty limited for GUI apps but it still shows that you can run some Win98 apps even in DOS if you have a VERY good DOS extender :-). > This is too bad, there is a lot of dos/9x software that doesn't > work well in NT. Even dosbox falls short in a lot of cases. Did you try in ReactOS? Dosbox was never meant to run Win98 software as far as I can tell. For DOS software, I do of course recommend FreeDOS, for example in DOSEMU or a virtual computer (bochs, vmware, qemu, virtualpc, virtualbox, ...). > but a lot of people fail to understand this and they give up > on an OSS project when it's author quits. Or even before that, for example in ReactOS ;-). Open source software always needs user input. For example you could use ReactOS even though you know it is very incomplete and help them by making suggestions which functions to repair/add first. > Is the sound card support built into mpxplay? If it is, that's > too bad. Generic support for post dos sound cards is sorely needed. This is where VSB and the fact that MPXPLAY is open source can help. VSB uses protected mode to trap all attempts of your DOS apps to a SoundBlaster. It then calculates which sound would have been generated and outputs that sound via your physical speaker. The simulation is minimalistic and only works without EMM386 and without DOS extenders but it is a start :-). And it is open source, too... You could probably modify it to work together with JEMM386 as a JLM (all EMM386 use protected mode but JEMM386 has a plugin interface for 'JLM' files) - then it can work with DOS extenders, too :-). As the original homepage (zap.eltrast.ru) seems to be down at the moment, I made a mirror of VSB. Happy testing :-). > www.coli.uni-saarland.de/~eric/stuff/soft/by-others/ (the two dos-virtual-sound... files from 1995 and 1996) Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Quoting Eric Auer <[EMAIL PROTECTED]>: > > Hi Flox, > >> read this post from the author of Mpxplay :-( >> https://sourceforge.net/forum/message.php?msg_id=5128817 > > Dunno if Arachne supports https, so I better paste it ;-) > > The post mentions that Emu10k SB PCI / SB Live 24 Audio LS > support got added, other cards from that family planned, > but there is a "by the way" about the future of DOS MPXPLAY: > >> it seems DOS users are less and less, and I don't think so that I can >> add too much for the DOS version of the Mpxplay (and I have/had too much >> problems with the LFNs, WATTCP (network) and with the extenders (ie: >> trying to play videos)). > >> Rather I'll continue the developing in a Win-GUI version. This means >> the end of the DOS development, because the GUI version requires a >> very different program structure and code than the current console >> version(s). So, probably this Mpxplay version will be the last DOS >> version (but I'll try to correct all bugs in it, before the final >> version)... > > My personal opinion here is that MPXPLAY is very nice for DOS > users because it supports many soundcards :-). The ability to > use network and video would not be a main issue for me. Maybe > Attila can continue updating the sound drivers for DOS while > focusing on Windows for the video support? > > Eric Depending on the licensing scheme for mpxplay, someone else can continue developing the dos version. The sad thing about developing a Windows version is that ReactOS, the only free Windows clone I know about, is years away from being something that is usable. There just aren't enough developers. Windows 9x is something better than a dos extender, but noone wants to develop a free replacement for that. This is too bad, there is a lot of dos/9x software that doesn't work well in NT. Even dosbox falls short in a lot of cases. Open source software is not as author dependent as traditional commercial software, but a lot of people fail to understand this and they give up on an OSS project when it's author quits. Is the sound card support built into mpxplay? If it is, that's too bad. Generic support for post dos sound cards is sorely needed. Michael C. Robinson This message was sent using IMP, the Internet Messaging Program. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Mpxplay won't be developed in the future...
Hi Flox, > read this post from the author of Mpxplay :-( > https://sourceforge.net/forum/message.php?msg_id=5128817 Dunno if Arachne supports https, so I better paste it ;-) The post mentions that Emu10k SB PCI / SB Live 24 Audio LS support got added, other cards from that family planned, but there is a "by the way" about the future of DOS MPXPLAY: > it seems DOS users are less and less, and I don't think so that I can > add too much for the DOS version of the Mpxplay (and I have/had too much > problems with the LFNs, WATTCP (network) and with the extenders (ie: > trying to play videos)). > Rather I'll continue the developing in a Win-GUI version. This means > the end of the DOS development, because the GUI version requires a > very different program structure and code than the current console > version(s). So, probably this Mpxplay version will be the last DOS > version (but I'll try to correct all bugs in it, before the final > version)... My personal opinion here is that MPXPLAY is very nice for DOS users because it supports many soundcards :-). The ability to use network and video would not be a main issue for me. Maybe Attila can continue updating the sound drivers for DOS while focusing on Windows for the video support? Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
