|
|
|
digression A digression
|
|
|
This came up accidentally when someone asked for a copy of an old program, and I found how D... big it was compared to what I am used to passing around. I have these two menu programs, one written in my usual F77_style_ and compiled with MS 3.31, which came to 44,676 bytes as an executable, and which runs in DOS or Windows command line or I can double-click on it in the directory, whatever, and it runs as expected, even on Macintosh DOS emulators (or pretty much any machine around). At some stage (2002, I think) I brought the source of this original F77 program into CVF 6.6 and compiled it as a command-line program to do absolutely the same job. There IS a difference. In the first program I call the SPAWN function for loading daughter programs for execution; in the Windows version I had to call SYSTEM to do the same job, one line difference, even though both actually use the SYSTEM function, but only the DOS program uses SPAWN. When these programs run, even I cannot tell which is which, since both appear as full screen programs with the same font and colours and so on, and no difference in behaviour at all. BUT, the windows-compiled version is 299,008 bytes long! Am I correct in assuming there must be unused code sitting in the larger Windows version? Obviously the two DO differ in one line of souce and so in executable content. But THAT much? So, anybody have any ideas on what percentage of overhead a typical for-Windows program carries? I was thinking, there would be some sense in have ONE all-the-windows- and-Fortran-library-stuff DLL, that and every main program loads first. I bought this point to the attention of Lahey, some time ago and they saw the point and permited the distribution of a loadable DLL( with most of the Lahey library inside), allowing small programs to be sent commercially and so updatable by sending new small replacement main modules. So if I have 60 Windows programs, I could l have say 60 small modules of about 60k each plus one humungous DLL of I guess 300K; total 3900k, instead of 60 times 300k or 18 Megabyte to distribute?. People wonder why I stick to F77 and DOS-in -Windows?
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|
|
|
digression A digression
|
|
|
When these programs run, even I cannot tell which is which, since both appear as full screen programs with the same font and colours and so on, and no difference in behaviour at all. BUT, the windows-compiled version is 299,008 bytes long! Am I correct in assuming there must be unused code sitting in the larger Windows version? Obviously the two DO differ in one line of souce and so in executable content. But THAT much? You were probably looking at the EXE size, right? What's happened is that the run-time library, because of cross-references and just a larger language, pulls in more code, including much that ends up not being used. It is possible to structure the library so less unused code gets pulled in, but nowadays a couple hundred KB is noise and you notice it only on small programs. Another thing is if the program is _link_ed against DLL libraries, the EXE will be smaller. Compare instead the size of the .obj file and you'll get a better notion of generated code size.
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|
|
|
digression A digression
|
|
|
BUT, the windows-compiled version is 299,008 bytes long! Am I correct in assuming there must be unused code sitting in the larger Windows version? Obviously the two DO differ in one line of souce and so in executable content. You were probably looking at the EXE size, right? What's happened is that the run-time library, because of cross-references and just a larger language, pulls in more code, including much that ends up not being used. It is possible to structure the library so less unused code gets pulled in, but nowadays a couple hundred KB is noise and you notice it only on small programs. Another thing is if the program is _link_ed against DLL libraries, the EXE will be smaller. Compare instead the size of the .obj file and you'll get a better notion of generated code size. There is a fair amount in .OBJ files that doesn't go in, such as external symbol lists and relocation information. If you want the real size, look at the _link_ map. It is an option in most _link_ers, including the MS _link_er.
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|
|
|
digression A digression
|
|
|
People wonder why I stick to F77 and DOS-in -Windows? Good luck. Vista does not run DOS graphics. Vista does not allow text in fullscreen mode. My good old DOS text editor runs like a dead dog in a console window... Eventually you will not have a choice. Old stuff just won't run anymore - or emulation will extract a large penalty in performance. Second, it's worth using some features of Fortran 95+. Free format, control structures, array operations, initialization _expression_s, parameter attribute, BOZ, stream I/O .... and others.
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|
|
|
digression A digression
|
|
|
Good luck. Vista does not run DOS graphics. Vista does not allow text in fullscreen mode. My good old DOS text editor runs like a dead dog in a console window... Eventually you will not have a choice. Old stuff just won't run anymore - or emulation will extract a large penalty in performance. IBM has done somewhat better at supporting old systems. Programs compiled (or assembled) for OS/360 over 40 years ago will still run under current z/OS systems. One that I have heard is the PL/I (F) compiler. The Fortran G and H compilers should also run fine.
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|
|
|
digression A digression
|
|
|
Second, it's worth using some features of Fortran 95+. Free format, control structures, array operations, initialization _expression_s, parameter attribute, BOZ, stream I/O .... and others.
|
|
|
|
|
|
|
The administrator has disabled public write access. |
|