RE: Installer for WJED available

[SANGOI DINO <SANGOID@xxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: John E. Davis [mailto:davis@xxxxxxxxxxxxx] 
> Sent: lunedì 21 febbraio 2005 22.13
> Subject: Re: Installer for WJED available
> 
> SANGOI DINO <SANGOID@xxxxxxxxxxxxxxxxx> wrote:
> >There is an installer for jed 0.99-16 compiled with slang 
> 1.4.9, and a 
> >more cutting edge jed b0.99-17.56 compiled with slang-pre2-r3.
> 
> Thanks.  Do you mind if I reference these from the jed 
> download web page?

I will be very glad if you do it.
 
> [...]
> >    * slang-win-slsh-makefile.diff:
> >      - Add a windows makefile for slsh (using mkmake.exe).
> 
> I just released the 5th development snapshot of slang2 and 
> included this patch.  Since I added readline support to slsh, 
> I had to modify makefile.all.  Also, to fully exploit slsh 
> under windows, its lib files will need to be installed 
> somewhere that slsh can find.  This happens with the 
> Makfile.g32 but not with makefile.all.  How difficult would 
> it be to get this working in makefile.all?

On Windows, installing all the things right is not easy, and we should be
able to handle different installations paths with the same binary. Now it
can be handled with environtment variables, but while this is a good
solution for unices, env. Vars on Windows are a mess. Even a simple
operation like setting a variable is hard: on Windows 95/98/Me you must edit
autoexec.bat. On WinNT/2000/etc. you need to write a registry key.

This is why I patched jed to get the JED_ROOT variable from the full
executable path: it saved me a lot of troubles in the installer.

So I can suggest a solution like this: I took the get_win32_root() function
from my jed patch, modified it a bit, ad used in slsh (see attached
slang-slsh-win-library-path.diff).

With this patch the slsh.rc and others will be find automagically, provided
that the installation prepared a directory structure like this:

Root/
	bin/
		slsh.exe
	slsh/
		slsh.rc
		autoload.sl
		( ... )

I'm also trying to be able to use modules on windows. The runtime linking is
very easy: Windows has functions that map mostly 1:1 to Linux dlopen() and
friends.

The problem is that Windows by default does not export symbols if not
explicity requested. You can request exporting using '__declspec(dllexport)'
on the function declaration, or creating a .def file containing all the
exported symbols, and passing this file to the linker.

The second solution is overkill for small modules, and difficult to keep
aligned, while the first is invasive, needs changes everywhere, even in
stuble places like in macro SLANG_MODULE in slang.h.

Oh, and while creating dynamic modules with a static slang.lib is doable,
it's not a good idea. But creating a   slang.dll again need
__declspec(export) or mantaining an external .def.

(I can do this work, either way, if John agrees).

One last thing: trying to compile jed b0.99-17.56 with slang-pre2-r5 I got a
couple of unresolved references for _Slsnprintf, _Slvsnprintf and
_SLw32_Hstdin.

I see that is is caused by the change:

0. src/*: For POSIX compliance, all _SL* symbols were changed to
   _pSL*.  Change suggested by Alastair McKinstry.  If you experience
   a linker error such as "undefined symbol: _SLChg_UCase_Lut" after
   upgrading, then you will have to recompile your application.

So, if you have not already patched jed, take a look at
jed-compile-with-slang2-r5.diff.

Thanks,
							Dino

Attachment: slang-slsh-win-library-path.diff
Description: Binary data

Attachment: jed-compile-with-slang2-r5.diff
Description: Binary data