retrostep-devel — Developer Mailing List

[rs-devel] dev: mod_ctl: kudos and user sanity

[Mudiaga O. <ob...@in...>]

I think it would be nice see modules support a new=20
(and optional) function that does a variety
of useful things.

One example of such a thing is what I think most people=20
would also like to see:

 - Display useful information about the module.
   - module name (full name)
   - authors
   - maintainer (who built it)
   - version=09
   - release date, build  date, etc
   - module homepage
   - url-to-go-for-help (email:x@y.org, http://y.org/x/, etc)
   - license (cough! cough!!)=20
     (e.g. "GPL", "BSD", "GPL5 (http: if not OSI approved), ..."

This (mostly optional) information need only be made availabe=20
to Litestep. What Litestep does with this information is its business.
However, much of what can be done should be obvious.


Now to the implementation (the programming):

I would like developers comment on this so that=20
everybodys wishes be taken care of. Of course=20
that does not include those whos needs can=20
never be satisfied.

As to this being inappropriate for this list, I have
already mentioned to jugg (on purels ML) that=20
litestep-devel@sourcefourge should be created. =20
And have all devels subscribe to it.


Currently litestep, uses LM_GETREVID which apart from
being lacking requires the module to CreateWindow().

The new callback API which the module provides should be=20
simple for module writers, but generic and be able to do=20
everything the future might require (think FreeBSD sysctl):

Now here's what I currently have in mind, and will do
for retro if I get no input:

   LSAPI const char * mod_ctl(const char * command,=20
		const char * command_param, char * command_data);


 + as for the module information mentioned above,
   Litestep will call it like this,

   mod_data =3D mod_ctl("about", NULL, NULL);
 =20
   and a module will do
=20
   if command =3D=3D "about" then=20
      return "MODULE_SIGNATURE: some-one-line-junk-can-go-here \n" \
	    "name: moduel request\n" \
	    "desc: This module solves all your computer problems\n" \
	    "module: moduel.dll\n" \
          "author: george at ojai.net\n" \
          "version: 256.5\n" \
	    "license: BSD";
    elseif command =3D=3D "something_else" then=20
	  do_something_else();
    else
	  return NULL; /* only requirement */
    endif


Even module databases can use this text format for feeding
module information into their database.

"MODULE_SIGNATURE": it is not just for sanity check.
If a module can't be loaded at all, a user can just
open the binary in a text editor and search for that
string to obtain the needed information.=20
Other apps can also do magic with it...

Note: please keep the retrostep-devel CC: in place.

Note: when I say "litestep", I mean ls-b24
by lsdev. And when I say "Litestep", I mean=20
litestep and more-or-less compatibles.

[rs-devel] opinion: litestep and possible conspiracies

[Mudiaga O. <ob...@in...>]

: This is in response to a mail by Message <Bgv...@ao...>
: to the litestep mailing list. I have posted this here
: and not as a reply as an attempt to be courteous=20
: to the litestep ML readers.


 > I would like that noone mention this shell with reference to=20
 > LiteStep. And it may fall upon deaf ears, but I would like all=20
 > references to LiteStep removed from said shell.=20

I will do so where appropriate.
However, I'm not totally sure if "Litestep Development Team"=20
will become "Development Team" or "Retrostep Development Team". <grin>

 > I am in the process of auditing the code, and I will request=20
 > any code of mine that I find removed.
 > I also request that all other developers do the same.=20

It never was a very good thing that Message is bent
on not having any of his code in retro.
Commanding others (err.. requesting without=20
having and giving sound reason) to do the same=20
is worse - they could also choose to allow=20
the code be used - if they have code in there).=20
I'll assume he is exercising one of the
privileges of being an lsdev.=20
However, he is going over the source.=20
It never hurts to look at other peoples sources.=20


I have this feeling people are doing
things just because they would like to
have a shell monopoly. I have to say I'm=20
not in a code war with anybody and my=20
willingness to share my code freely
is not affected. If anyone is at war=20
with me, he is in a one sided war.=20
I won't speculate on what there is to win.

One question one needs to ask is, if some=20
people have energy to fight, why don't they=20
just go and fight on the Phoenix battleground=20
and bring progress there instead of taking=20
"retrostep" as a literal instruction and=20
not wanting to move forwards.

If you are a module writer, you have nothing
to worry about - just make your module compatible=20
to both purels and litestep.
On a paranoid note, if you see an API in lsapi.dll=20
that uses a "magic value" or introduces complex=20
data structures, try not to use them.=20
lsapi.dll data structures should be opaque to modules.
Now that is too much asked is it?

All the same, if I send anybody code improvements=20
for a certain module and they refuse to add it to
the module for no good reason, that module better=20
be violating the GPL (under which all modules up=20
till now are  released right? right.) because if=20
I really want that feature in there, I will fork
the code - not good for me, not good for him,=20
not good for you.

Rats! I see them going to hide the sources...=20
other peoples sources....  But I feel no loss
because demigod has already spoken.

[rs-devel] RE: RE: [Litestep] Retrostep - Anyone tried it?

[Mudiaga O. <ob...@in...>]

NOTE:

You might get a BCC of this if i don't think you're on
the rs-devel List.

Just another mail turn into rant. I like that cause I
usually won't write stuff like this.  If my mood allows
I take full avantage of it :-)

=========================================================

It would be nice if you subscribed to the ML and you 
direct further mails there so that other people can benefit.

 > >Hmm... You can actually can recycle without crashing? :-)
 > 
 > Yes.  If I don't load shortcut2 it recycles fine, except for 
 > that then it locks up.

Thanks. It's been fixed just had to move code arround.
Diff file will show up in rs-devel ML ...

 > Forgive me for coming to the topic late, but what makes retrostep
 > different from PureLS?

Please forgive me too for asking you be patient until
somebody documents this (hopefully not me).
I've tried CCing mails I sent regarding retro features 
to the rs-users ML - if you look up the archive you might find
relevant information. 

But come to think of it, I don't think I've addressed the purels 
issue directly. I'll just rant some so I can send it to the 
rs-users ML.

Other than being ahead of purels on a feature matrix,
the difference from purels should be that retro has
grand plans, has litestep compatibility as high priority 
(although it will be difficult if litestep devs do not
wish to see this happen) tries to keep code simple and 
clear, and the it is hoped that it's developers will 
try to do more than just shrug when users request a feature.

On thing about the retro code itself, is that it will never 
be bothered by certain things. Let's take unicode as an
example. purels use of <tchar.h> is misguided
because it is impossible for #define _UNICODE to do
do magic and proxy legacy modules for you.
retro will stick to the fact that it's not it's job
to display text to the user, it will assume it's
dealing in with a popular multibyte encoding.
It will document the fact that it's behaviour 
if giving non-ASCII strings is undefined.
See the comments in the file str_lib.h for more info.

If retro can avoid a problem, it shouldn't try to solve it.
Making the std API encoding utf-8 or utf-16 is far from a 
solution because it we would require modules to do conversions.
If module writers tell us they need a solution to
their problems, we'll trow in some easy-to-use conversion 
routines into lsapi.dll and we have it.

retrostep will keep all OLE/COM calls to shell32.dll
(which more or lesee require explorer) out of the core
and thus optional.  Retrostep will get alternate modules....
When contributors code, they should keep that in mind.
(see the prototype lsexsh32.dll in the distribution
where most things what are trying to immitate explorer
should go). This should make if easier on small machines,
or if somebody wants to debug retor by running it under WINE.
I don't know how purels is doing the COM aspects of the 
Win2K icons things but I'm sure they can learn from retro
on who it should be done - Ender would like it that way too.

Note that I do not deceive myself about the importance of
memory foot print and speed and have thus not looked
at it any futher. But judging from things I know
about both sources, retro should be more efficient 
with your resouces.  Did you know that the file
size of lsapi.dll is considerably affected by amount 
of text messages and other non-code it contains?
And that it does lots of sanity checks?

Hope that gives you a good enuf Idea to know that
retro is really another beast of it's own. 
It's really hard to compare these things. 
Even purels vs. litestep is not easy - apples and
oranges - but folks just make some lame statement, 
agree that purels and litestep are not competing 
and leave it at that.
Licensing differences should not belong in any
diff/pro/con discussion about the other steps.
The silly things are both under GPL, and have 
been arround for a while and they mostly 
can't/don't/won't share code.
So much for the use of the License they are under.

[rs-devel] retrostep-start bug fixes

[Mudiaga O. <ob...@in...>]

Here are the fixes for known bugs:
These where things I changed very recently...
As alwys, Less code, less bugs.

Bug-1: mudi

Silly code unloads a dll immediately atfer
a dialog box is closed. If another is open,
leads to crash.

Fix: we just LoadLibray and FreeLibray=20
every time and let windows do ref count.
(will get to that when edit box handling
get's abstacted and put in own file as
stated in the TODO about ui_init.c)

Bug-2: (repugnant)

Another Silly bug: changed things without thinking.
Here's why it crashs:

msg_lib=20
  -> msg_dispatch(WM_RECYCLE)=20
       -> destroy msg_lib=20
  (there is no valid data in msg_lib on return - crash)

Fix: LM_RECYCLE handler must go back to retro.exe and=20
  not be activated via msg_lib