DOS ain't dead

Have anubodz tried this library? Is it comparable to Watt32 or is it better? (or worse?)
Maybe it could be used in MPXplay instead to Watt32?
http://www.softsystem.co.uk/products/swssock.htm

---
DOS-u-akbar!

> Have anubodz tried this library? Is it comparable to Watt32 or is it
> better? (or worse?)
> Maybe it could be used in MPXplay instead to Watt32?
> http://www.softsystem.co.uk/products/swssock.htm

No. I noted as per this announcement Lawrence Rust / Software Systems have now stopped developing several past products, however their products page clearly lists what is and is NOT still maintained.

I noted that in addition to the freeware SWSsock library, Lawrence has also kindly produced and maintains several other open source items which all support 32bit DOS builds:

SwsMtc - A multithreading library for C and C++ programs that is open source, cross platform, small footprint and high performance.

SimUtil is a cross platform, command line utility to load or save the mobile SIM card phone-book.

ScUtil is a cross platform, interactive command line utility that provides in-depth examination of ISO 7816 smart cards e.g. bank cards, mobile phone SIMs etc


So good find! Thanks Lawrence/Software Systems!

Also see that SoundFX was made opensource
http://www.softsystem.co.uk/products/soundfx.htm

---
DOS gives me freedom to unlimited HW access.

> Have anubodz tried this library? Is it comparable to Watt32 or is it
> better? (or worse?)
> Maybe it could be used in MPXplay instead to Watt32?
> http://www.softsystem.co.uk/products/swssock.htm

I tried to download this lib and it compiled without any warning under my DJGPP 2.04 and all apps works fine (on my RTL8111 with NDIS->PKT wrapper). Binaries are much smaller than with WATTCP. Hehe who wants to write a web browser with it?

---
DOS gives me freedom to unlimited HW access.

I have no real DOS network, so I've installed the SWSVPKT (virtual packet driver for Win) from the same site. The SWSScok DOS sample programs seem to work (partially), so I will try to add/link the library to Mpxplay. But I don't promise anything...
btw. the WATTCP version of Mpxplay doesn't work in the same environment, so we should forget that stuff...
(the DHCP fails, with fixed IPs the program logging in, but crashing after this point)

Great to hear it!
The current Watt32 based Mpxplay doesn't work for me either.
(on the real DOS machine with network and packet driver)

---
DOS-u-akbar!

> Great to hear it!
> The current Watt32 based Mpxplay doesn't work for me either.
> (on the real DOS machine with network and packet driver)

So, I've made a new test version with the SWSSOCK library.
You can download it from http://www.freewebtown.com/mpxplay/test/test.htm
I used the Win32 Virtual Packet driver for the testing, but it hangs at "logging in..." at me (Mpxplay writes some status messages in the id3-window).
I wonder that how does it work in a native DOS environment.
(maybe you have to modify the SWS_SOCK.INI file settings)
Currently the DOS/SWSSOCK source code matches with the win32 one, so if it doesn't work at you too, then I have to do a deeper debug and maybe strong modifications (I don't know when will I have time to do it)...

Great! I will test it in friday.

---
DOS-u-akbar!

> So, I've made a new test version with the SWSSOCK library.
> You can download it from
> http://www.freewebtown.com/mpxplay/test/test.htm

Great

ftp://ftp.openbsd.org/pub/OpenBSD/songs/

Good things:

- I can see the directories ^^^ and browse them
- If I disable autoloading (search for MP5 metadata ???), I can see the MP5 and OGG files too

Bad things:

- File download (even autoloading) doesn't work and hangs, need to push RESET
- Some servers work partially and some not at all (they do work in Arachne)
- There should be an option "show all files" besides "show supported files and subdirectories only"

I acquired my IP from DHCP using Arachne previously.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> - I can see the directories ^^^ and browse them
> - If I disable autoloading (search for MP5 metadata ???), I can see the MP5
> and OGG files too

"disable autoloading": you mean -inl option? Yeah that is recommended on such slow servers. MP5? What is it?

> Bad things:
>
> - File download (even autoloading) doesn't work and hangs, need to push
> RESET

I couldn't reach this point with win32 virtual packet driver yet...
If the -inl option doesn't work, maybe you can try the -bn8 or -t options too.

> - Some servers work partially and some not at all (they do work in
> Arachne)

1. At my tests, sometimes the timeout value was low, I will change it.
2. Some old servers send back messy replies/answers, I will try to fix this (server side) problem in Mpxplay. But not in v1.57 .

> - There should be an option "show all files" besides "show supported files
> and subdirectories only"

Yeah, this is missing. I put it on my todo list...

> I acquired my IP from DHCP using Arachne previously.

I don't understand. You used fix ip address or dhcp at Mpxplay?

Thanks for the testing anyway.

So, it seems the SWSsock is more promising than the WATTCP.

> "disable autoloading": you mean -inl option?

I edited MPXPLAY.INI

> If the -inl option doesn't work, maybe you can try the -bn8 or -t options

I will

> I don't understand. You used fix ip address or dhcp at Mpxplay?

DHCP. But acquired IP previously with Arachne so MPXPLAY had less chance to fail / hang / timeout at this task (as it's apparently easier to "ask" for already available IP than acquire ...).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> So, I've made a new test version with the SWSSOCK library.

How much differs the swssock api from wattcp? Is it possible easy porting other apps from wattcp to swssock? I don't have any experiences writting network stuff, sory.

---
DOS gives me freedom to unlimited HW access.

> How much differs the swssock api from wattcp?
> Is it possible easy porting other apps from wattcp to swssock?

Both library have their own and standard (BSD http://en.wikipedia.org/wiki/Berkeley_sockets) api too.
If somebody used the WATTCP's non-standard api, then it will be a couple of work to apply the source to SWSsock.
I think so Mpxplay's ftp-server side is such thing...

And it was a little complicate to compile SWSsock with Watcom. Probably this part of the source was never tested. I wrote a completely new makefile, took out a couple of include files from WATTCP and merged to SWSsock, and modified some include files/definitions.
But I've uploaded the compiled library (with all of the required include files) to my test page, if somebody wants to use it...

> I don't have any experiences writting network stuff, sory.

I also have not too much...

If I open "ftp://ftp.openbsd.org/pub/OpenBSD/songs/" it successfully loads the filelist fith MP3 and OGG files.
Then Mpxplay tries to load the file infirmations from server - in the filelist gradualy occur the lengths of the songs. But this process is EXTREMELY slow, it almost looks like computer is frozen but after some period changes the status message to "dataconn (file/dir) open failed" or "read retry".

Then I tried to connect into my site on ftp.laaca.borec.cz (with proper username and password). It was succeful only after more tries but also got a partial success,
The files and directories were dislayed but it was not possible to enter the subdirectories. Mpxplay wrote: "Opening ASCII mode connection" and then "no file" and nothing more happened.

I have done this tests with static IP adress specified in configuration file.

---
DOS-u-akbar!

I've found a problem, that the Virtual Packet driver (and probably other DOS packet drivers too) doesn't like my one-byte response reading. I've already made a line/block based reading too (it's in the source), but it also failed sometimes (at my strong tests).
The file opening problem is an other thing, it exists in the win32 version too.
So, I see the problems, I will work on them (but I don't know when)...

> I've found a problem, that the Virtual Packet driver (and probably other
> DOS packet drivers too) doesn't like my one-byte response reading. I've
> already made a line/block based reading too (it's in the source), but it
> also failed sometimes (at my strong tests).
> The file opening problem is an other thing, it exists in the win32 version
> too.
> So, I see the problems, I will work on them (but I don't know when)...

I've updated the test page and TCPIP version of Mpxplay on http://www.freewebtown.com/mpxplay too.
I've modified the response reading, so the directory browsing should work, but the file opening still can be wrong on the openbsd.org, because - I think so - it sends back a welcome message at file opening, which is not handled in Mpxplay yet (because it's non-standard and bull*hit anyway).

> I've updated the test page and TCPIP version of Mpxplay on
> http://www.freewebtown.com/mpxplay too.
> I've modified the response reading, so the directory browsing should work,

Probably I was wrong.
There are a couple of problems with the 10-15 years old ftp servers, which are not handled in Mpxplay (directory and file handling/reading). I've developed my ftp client on Filezilla server, so Mpxplay works properly on it (and on ftp server of my internet provider too), but on older servers Mpxplay can fail.
Maybe later I will try to do something, but currently these bugs seem too much work. This is similar like to implement pc speaker handling...

I've updated the test versions (I've made a win32 one too). Please try...
http://www.freewebtown.com/mpxplay/test/test.htm

> If I open "ftp://ftp.openbsd.org/pub/OpenBSD/songs/"

1. try "ftp://ftp.inet.no", it's faster, but both servers (the latter surely) don't handle the "closing the file befor eof" (eq to ABOR command, but I just simply close the socket), so the file handling is still very slow there (if the file-close fails, Mpxplay must close the session too and reconnect (automatically)). Use -inl -in options.

> Then I tried to connect into my site on ftp.laaca.borec.cz (with proper
> username and password). It was succeful only after more tries but also got
> a partial success,

If the latest (2010.07.12) version still doesn't work on your server, can you make me an access/login for it?

Yeah! Version from 12.7. is great leap forward!
Finally I am able in most of cases to play files from internet!

Some servers works perfectly some worse.
1) ftp://ftp.freepascal.org
ftp://ftp.inet.no
These work amasing, everything is fast and without problems

2) ftp://ftp.openbsd.org/pub/OpenBSD/songs
ftp://mpxplaytest:mpxplay@mpxplaytest.ic.cz
These wotk worse, it everytime waits until some timeouts and retries, however when I browse into subdir with MP3 I am able to play them.

3) ftp://mpxplaytest.wz.cz:mpxplay@mpxplaytest.wz.cz
Has serious problems with connrcting and logging. However after few tries it successes and with some luck is even possible to play MP3 files. However sometimes certains errors occurs like "Password required for this server" or "You can't be logged more than two times"

4) ftp://ftp.delorie.com
Here is something seriously broken. I can login but I see cripled sile names and can't browse into subdirectories.

edit 14.7. in 22:45:
I mistyped the login for IC.CZ server in this post. Corrected

---
DOS-u-akbar!

Thanks to Laaca and Mpxplay ... I'll download and test

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Thank You for the testing!
ftp://ftp.freepascal.org has no audio files (I've scaned with F5)
ftp://ftp.inet.no has file downloading problems at me (file-close bug)
ftp://ftp.openbsd.org/pub/OpenBSD/songs is a very slow server at me (around 100 kbit/s)
But the directory handling is good on these servers.

ftp://mpxplaytest.ic.cz:mpxplay@mpxplaytest.ic.cz is currently offline? (Firefox also can't open)
ftp://mpxplaytest.wz.cz:mpxplay@mpxplaytest.wz.cz has interesting directory reading problems. The file playing seems to be good, just something is wrong with the "Cechomor:Neber sobe" song...
ftp://ftp.delorie.com has the same directory reading bugs and the filenames are bad, I will check this, but I'm not sure that I will modify the LIST command handling/reading in v1.57

btw. it's good to test a couple of different servers...
"550 SIZE not allowed in ASCII mode" is new for me...
(mpxplaytest.wz.cz says this)

> ftp://mpxplaytest.ic.cz:mpxplay@mpxplaytest.ic.cz is currently offline?
> (Firefox also can't open)


Ummh...
I am sorry, it shall be:
ftp://mpxplaytest:mpxplay@mpxplaytest.ic.cz

---
DOS-u-akbar!

Updated again (2010.07.19)...

Login problem of to wz.cz is not corrected yet, some other bugs fixed (I hope so): directory handling of wz.cz and delorie.com, and I've found a file handling bug too (but ftp.inet.no is still buggy).

ic.cz still doesn't work...

I've added a new flag to desktopmode: +4 show all filenames/filetypes in directory browser. It displays only filenames, it doesn't write the filesize and filedate yet (you can get this info with F3 only).

> ic.cz still doesn't work...

Connected to ic.cz.
220 ProFTPD 1.3.0 Server (IC.cz ftp server)

The OLD version of ProFTPD used on ic.cz is circ 2006 and has *many* issues including several login related issues, e.g. ProFTPd 1.3.0 rejects login. That particular version also has other serious issues... I thus suggest that Laaca upgrades asap to a more recent version of ProFTPD such as 1.3.3a and then retest with MPXplay.

> Connected to ic.cz.
> 220 ProFTPD 1.3.0 Server (IC.cz ftp server)

I cannot reach this point with Total Commander neither.
I don't get back any response from the server (from here/Hungary)...

> I cannot reach this point with Total Commander neither.
I have received the initial connect from 2 different connections several times over without any major problems, to be honest I didn't try logging in any further.

I did also wonder if Laaca's firewall is probably doing packet inspection as when I dropped a connection and tried again too soon my connection was denied access, so I waited 30 seconds tried again and all was ok. Either that or I was just seeing the known connection bugs in the old version he is running which is one of the reasons I have suggested he ditches that version asap.

> I don't get back any response from the server (from here/Hungary)...
Matav RIP :( Have you tried with netcat? At the least you should get the following:

q:\>nc ftp.laaca.borec.cz 21
220 ftp server ready
421 Login Timeout (30 seconds): closing control connection.
q:\>

Note: However the above quick test wasn't done using a DOS version of NetCat, however for anyone reading this unfamilar with it there are several Variants, e.g:
Busybox (Linux),
GNU Netcat (Linux)
Win32 version (Win32 programmers blog notes)
Win32 MinGW version
etc.

Mike (Brutman) has also released a new DOS port as part of mTCP, the background of which can be found here: http://brutman.com/mTCP/mTCP_Netcat.html. Mike's version can be downloaded with mTCP.

As Mike points out on his page you can pretty much do anything with NetCat, e.g. like Mike I've used it to send emails but have also used it to connect to more complex protocols such as FTP and IRC. FTP is straight forward but I'd not recommend IRC as that is a bit like writing a long document in debug - yes you can but there are far easier tools ;) Still like debug, netcat is extremely useful especially when trying to track down or recreate networking / telnet based protocol (SMTP, FTP etc) issues. Unfortunately though some anti-virus software incorrectly (in my view) flag up netcat as being malicious, so just be aware of this if you've never downloaded/used it before.

> > I don't get back any response from the server (from here/Hungary)...
> Matav RIP :( Have you tried with netcat? At the least you should get the
> following:
>
> q:\>nc ftp.laaca.borec.cz 21
> 220 ftp server ready
> 421 Login Timeout (30 seconds): closing control connection.
> q:\>

30 secs timeout? I think so most programs don't use such long timeout.
I use 6 secs, it's usually enough. If the server doesn't respond within 6 secs, then something is wrong (on the server side, or in the line)...
Mpxplay runs an auto-reconnect in this case. The short timeout is for the continuous playing, to avoid buffer underrun. For the login process I will change the connection-check and the timeout-length too.

> > q:\>nc ftp.laaca.borec.cz 21
> > 220 ftp server ready
> > 421 Login Timeout (30 seconds): closing control connection.
> > q:\>
> 30 secs timeout? I think so most programs don't use such long timeout.

That time out is at Lacaa's end. Looking at the Proftpd config documentation I noted the default Login timeout value is apparently 300 seconds!!! Yup, seconds!

> I use 6 secs, it's usually enough. If the server doesn't respond within 6
> secs, then something is wrong (on the server side, or in the line)...
That is probably too low a value at least for an initial connection.

> I will change the connection-check and the timeout-length too.
Ok, I suspect this will help Lacaa. Regardless of mpxplay I'd still strongly recommend that Lacaa upgrades his FTP server to use a more current version asap.

The feature list is impressive, and you can't beat the price. I'm curious about the performance and how much memory it takes.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

Yesterday I tested the last build. The results are good, it is another leap forward, the FTP handling IS better.
ftp://ftp.delorie.com now works OK and the handling of servers by WebZdarma company (wz.cz and borec.cz) is also better. Stil remains some minor issues with my laaca.borec.cz site but it is fully usable now. (I sent personal mail with username and password to Attila for test)

So, I think we can say that FTP handling is basicaly done and now some advanced improvements should be done.

1) the +4 desktop mode is great feature. Now the usability could be extended by implementing some hotkey for saving (downloading) files from FTP server into local disk.

2) if I press CTRL-F I would like to see some simple menu with four and five preset FTP connections and one inputline for typing another connection (like now)

3) the CTRL-F and CTRL-K keys should be described in F1 menu

4) all files displaying and supported files displaying should be possible to switch inside Mpxplay - not only by editing the mpxplay.ini file.

---
DOS-u-akbar!

> Yesterday I tested the last build. The results are good, it is another leap
> forward, the FTP handling IS better.
> ftp://ftp.delorie.com now works OK and the handling of servers
> by WebZdarma company (wz.cz and borec.cz) is also better. Stil remains some
> minor issues with my laaca.borec.cz site but it is fully usable now. (I
> sent personal mail with username and password to Attila for test)

Ooops, I've uploaded a newer version before I read my mails.
But now I've tested your site too, the first login worked (I could play the mp3 files too), the second one failed after the 30 sec timeout (at waiting response to PASS command), the third one worked again...

Modifications in the last build (2010.07.25):
- 3 different timeout for login (30 secs), message and directory read (15 secs) and file-read (6 secs)
- faster/immediately detection of lost connections at message reading too (faster - but still very slow - file handling on ftp://ftp.inet.no)
- added windows nt directory handling (previous versions read unix style only) (tested on ftp://193.43.36.131 )
- direct ip addresses (like above) handling in DOS version (I don't know where is the bug, maybe in the win32 virtual packet driver, but I've implemented a bugfix on Mpxplay's side)

> So, I think we can say that FTP handling is basicaly done

I hope, now it is, but a program is never finished...
And tell me, if you find a server, which doesn't work with Mpxplay (but works with other programs like Firefox or TotalCommander)

> 1) the +4 desktop mode is great feature. Now the usability could be
> extended by implementing some hotkey for saving (downloading) files from
> FTP server into local disk.

There is an ALT-F5 for file copy...
But it's very slow, if you play and copy too from the same server/session, so pause/stop the music, then copy the file. Mpxplay doesn't open automatically a new session for the secondary file. (you can do this manually, if the server allows multiply login)

> 2) if I press CTRL-F I would like to see some simple menu with four and
> five preset FTP connections and one inputline for typing another connection
> (like now)

I plan...

> 3) the CTRL-F and CTRL-K keys should be described in F1 menu

No space to put all keys there...

> 4) all files displaying and supported files displaying should be possible
> to switch inside Mpxplay - not only by editing the mpxplay.ini file

Almost all keys mapped to a function already... (e,ctrl-e,f,ctrl-f,i,ctrl-i are busy). Yeah, a config menu is missing from Mpxplay... I will look around...

Anyway, thnx for the tests!

(recently I tested Arachne and mFTP only so far see other thread)

http://www.freewebtown.com/mpxplay/test/test.htm

> For DOS ftp-client test:
> Mpxplay v1.57 beta 6.5 DOS32A + SWSSOCK library (2010.07.25.) (compiled with OW 1.3)
> Mpxplay v1.57 beta 6.5 Win32 console (2010.07.25.)
> Mpxplay v1.57 beta 6.5 source (2010.07.25.) (the default link config is for a DOS32A executable)
> SWSSCOK library for Watcom/Mpxplay (compiled with OW1.9)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

see subj thanks I can play from FTP now.

Issues:

[BUG 0] - MPXPLAY.INI is preset to volume "D:" , If such doesn't exist, it displays garbage

[BUG 1] - OGG timing is garbage (at least for Vorbis+Theora). VLC 1.1.1 (major update 3 days ago) also suffers from this bug. MPLAYER also suffers from this bug. DUGL PLAYER also suffers from this bug.

[BUG 2] - "kbit" is apparently garbage for some (Vorbis+Theora) files, and this garbage is too long and exceeds the field reserved for it.

[flaw 3] - FTP seems to "hang" - maybe put a progress/timeout indicator somewhere (bottom line of screen) ?

[flaw 4] - FTP needs a "sophisticated" syntax, otherwise it just miserably fails. It doesn't bother to ask for username or password.

[flaw 5] (old) - buffer indicator gets red when approaching EOF, Why not just place a white "EOF" instead ?

[sugg 6] (old) - built-in screenshot feature

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> [BUG 0] - MPXPLAY.INI is preset to volume "D:" , If such doesn't exist, it
> displays garbage

Interesting. I've put a wrong mpxplay.ini in the test DOS releases... thnx

> [BUG 1] - OGG timing is garbage (at least for Vorbis+Theora).

Thnx. Almost all containers have something bug. I will try to work on them in the next v1.58.

> [flaw 3] - FTP seems to "hang" - maybe put a progress/timeout indicator
> somewhere (bottom line of screen) ?

There is a timeout indicator (appears after 1.5 sec), but there isn't progress one. When do you see the "hanging"? At directory changes? I can implement it...
If it "hangs" at file opening: it's 3-4 steps (file seeks) and 10-12 ftp commands to play a file. If the message communication is slow, it looks like the program is hanging for 2-3 secs. I will think on it, but currently I cannot add pprogress indicator for the file opening process, I mean I don't want to display all ftp commands/status on the screen...

> [flaw 4]
> [flaw 5]
> [sugg 6]

Missing features...

> > displays garbage
> Interesting. I've put a wrong mpxplay.ini in the test DOS releases... thnx

The solution is of course not to just use "C:", but to check for volume validity / list of valid volumes, and be prepared to the possibility that there is none. Remember that now we can use MPXPLAY on a PC with no hard disk (having some network instead)

> There is a timeout indicator (appears after 1.5 sec), but there isn't
> progress one. When do you see the "hanging"?

When reading out all the metadata (long names & Co) from audio files having such (MP5, OGG Vorbis, ...).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> The solution is of course not to just use "C:", but to check for volume
> validity / list of valid volumes, and be prepared to the possibility that
> there is none. Remember that now we can use MPXPLAY on a PC with no hard
> disk (having some network instead)

The mpxplay.ini in the test release has "D:\" directory on left side and "C:\WC\MPXPLAY\MPXP1000.CUE" playlist on the right side.
At my (fast) test, the problem is the non-existent playlist on the right side. The program stands on the right side at startup, even if it cannot load the playlist. We have to press a TAB to see/get the editor-bar.
I think so the non-existent drive/dir is handled, but I will test it again...

> 4) all files displaying and supported files displaying should be possible
> to switch inside Mpxplay - not only by editing the mpxplay.ini file.

I've modified the 'E' key, now it switches to a kind of file-commander mode.
All files, filenames, filesizes and filedates are displayed in this mode (instead of artist, title, song-length)

Oh, of course in the new beta 7...

ps. some small bugs (and missing optimizations) are possible yet...