has anyone done any winsock communications with the cvf6.5?
Would be obliged. Tim
I have done tcp and udp sockets work since FORTRAN 5 (or 4). It's a little ugly - but has worked fine for many years - the FORTRAN socket code I built communicates 50 times a second to another machine and I have over 20 instances of it running for over 2 years. I believe there was one improper type for one of the Win32 calls. The rest of the work was straight forward. Now, You may be able to hit some ActiveX components instead of doing all the System calls. What do you have in mind?
If you are using Http, Ftp, or Gopher protocols, you're better off using WinInet APIs then Winsock. For WinInet, I can recommend Aaron Skonnard's book Essential Wininet as a supplement to the documentation. But if your intentions lie outside those three protocols, you're stuck rolling your own with Winsock.
CVF 6.5 doesn't ship with a wininet module, but I have a CVF translation of the wininet.h header file available here.
John, you re-surprise me each time :-). I started translating it sometime in October and stopped at half, wondering when I will find some time to finish it. Regarding sockets, I found an interesting C source in comp.os.ms-windows.programmer.win32 ng, if you don't mind translating it into Fortran. I'm also interested on the topic, but, as I said above, I didn't have time to work on it.
I'll make you a deal on winsock2.h. I'll translate the #defines and UDTs if you'll do the function prototypes. ;-)
Seriously, hand translation (done right) is too tedious and time consuming. In the future, my billing rate will be fairly high. :) If you want to, let me know if there are any interesting differences between what you have translated and what mine looks like.
John, we got a deal :-). There are ~85 function prototypes, shouldn't be too hard. However, I see quite a bunch of macros -- what about them? What UDT stands for?
Regarding WinInet, I started translating from top to bottom, did Find&Replace for all relevant keywords and then went to converting typedefs and function declarations; I came to about half. Btw, does anyone know why, in the F90 standard, scope of INTERFACE declaration is "isolated" from outer scope, i.e. why
END SUBROUTINE f_foo
END MODULE Header
isn't legal, and, moreover, INTERFACE cannot USE module where it is defined, so the module must be broken into two, one with interfaces and another with declarations?
John, I suggest that we continue by e-mail (firstname.lastname@example.org), since this wents out of scope of this forum.
UDT - User Defined Type, aka, derived type (f90), struct (C). Sorry :).
macros? you get those too, of course. :) Really, I was hoping you were just kidding. I'll send you email.
Interface blocks have their own scope. Host association is not extended to interface blocks. And a module can't access itself. I used to remember from c.l.f. posts why this is the case, but I can't recall now. I know that Metcalfe and Reid 2nd ed. discusses it briefly. This issue is broadly considered to be a pain in the neck. Supposedly F2k+ will support a new keyword (import?) that will relieve one from hoisting dependant derived-types into their own module.