windows 9x trials

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

windows 9x trials

Paul Kienzle-2
All,

Is there anyone else out there who is using oct-files under
Windows 95-98-ME?  

I'm still having difficulty with, e.g., "min.oct has caused
a error" message box popping up for each oct-file that has
been loaded whenever octave forks.  It does this a lot, like
every time the pager is called unless page_screen_output = 0.  
It works for me under Windows 2000.  Does it work for anyone
under 9x?

I tried writing a trimmed down program which did a dynamic
load then a fork, but I was not able to reproduce the problem.

I'm finding fork under cygwin is painfully slow for windows
9x.  Other than, "so don't do it", are there any suggestions?
"Don't do it" will require a couple of changes to the way
things are done.  We would need to build in a pager.  And our
own ls, but that should be easy enough. Texinfo will continue
to be a problem.  

I suppose we could preprocess all the texinfo help and put
them in a separate files (e.g., .hlp), possibly on a
separate path.  Octave would have to know to look on the
other path or for the other extension first before grabbing
the doc string from the function.  We may want the ability
to separate the help from the function anyway so that users
can have help in their own language, assuming someone wants
to work on the translation.  Translation of error messages
and other internal strings is a separate problem.

I built a shared version of Andy Adler's most recent octave
for windows install exe.  Install size 130 Mb before stripping
the oct-files, 65 Mb after.  Distribution size is 13 Mb
compared to Andy's 4.5 Mb.  

Looking through one oct-file prior to stripping with nm, most
of the symbols seem to be related to iostream.  Indeed,
recompiling my dynamic loading example from yesterday, dynsub.dll
jumps from 21 kb to 454 kb just from using iostream.  Is there
some way of telling g++ to only put iostream in the exe and not
in each of the dlls?  Or better yet, leave it in a dll and link
to that?  Cygwin only has libstdc++.a, but this may just be an
interface to some unnamed dll and not the implementation.  Would
compiling libstdc++ as a dll solve oct-file size problem?  Is
there a regular on the cygwin list who could ask the question
there?

Thanks in advance,

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: windows 9x trials

Paul Kienzle
Paul Kienzle wrote:

>I'm still having difficulty with, e.g., "min.oct has caused
>a error" message box popping up for each oct-file that has
>been loaded whenever octave forks.  It does this a lot, like
>every time the pager is called unless page_screen_output = 0.  
>It works for me under Windows 2000.  Does it work for anyone
>under 9x?
>
The problem only occurs if I link against a shared version of
liboctinterp.  It doesn't
matter if I use any symbols from it. Linking to liboctave or libcruft
does not cause
a problem. Here is as small as I can get the problem for now.  Run
dynmain to see
that it works when not linked to liboctinterp, and dynerr to see that it
fails when
linked to liboctinterp.

Note that the Makefile assumes liboctinterp.dll.a is in
/octave/lib/octave-2.1.43.

Any suggestions why linking to liboctinterp.dll.a would cause system()
to think
there is an error in every library loaded by LoadLibrary() on Windows ME
(and maybe Win98) but not on Windows 2000?

Paul Kienzle
[hidden email]

--- dynmain.cc ---
#include <iostream>
#include <windows.h>
int main(int argc, char *argv[])
{
  HINSTANCE handle = LoadLibrary("dynsub.dll");
  std::cout << "# Calling system\n";
  system("ls");
  std::cout << "# continuing\n";
  return 0;
}

---- dynsub.c
#include <stdio.h>
void dynsub(void) { printf("in dynsub\n"); }

--- Makefile
all: dynsub.dll dynmain.exe dynerr.exe
dynmain.exe: dynmain.o  ; g++ -o $@ $<
dynerr.exe : dynmain.o  ; g++ -o $@ $< -L/octave/lib/octave-2.1.43
-loctinterp
dynmain.o  : dynmain.cc ; g++ -c dynmain.cc
dynsub.dll : dynsub.o   ; gcc -shared dynsub.c -o dynsub.dll