retrostep-devel Mailing List for retrostep shell for windows
Status: Beta
Brought to you by:
obada
Menu
▾
▴
retrostep-devel — Developer Mailing List
You can subscribe to this list here.
| 2002 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
|
May
(18) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Mudiaga O. <ob...@us...> - 2002-05-07 12:04:50
|
Thanks to Pavel Vitis, retrostep numerous bugs have been fixed. Attached you'll find a patch to .5.11 (the next release hopefully). If you have the .5.10 sources, you can apply the patch to the sources with the following command: cd %dir_where_rs_5_10_is patch -p 1 < rs_obada-0.0.5.11.patch (of course, that's from the cygwin shell) Here's from the Changelog: user: obada date: 2002-05-07 fixed: LSExcute using "open" instead of NULL as verb for ShellExecute notes: LSExcute should also handle directories correctly with NULL notes: fix pointed out by pavel changed: disabled \" stupidity in Startup runner (shrunner.c) todo: will remove later later user: obada date: 2002-05-06 changed: disabled win.ini/load I think that's winlogon's job... user: obada date: 2002-05-06 fixed: match() was case sensitive fixed: !none now handled as (void)0 notes: test for "!none" equality was wrong "no bang command ..." never shown fixed: built-in hotkeys now registered after modules loaded and not before notes: thanks to pavel added: Win+C now bound to emergency command console as built-in user: obada date: 2002-05-02 added: !tray.dump for spying on tray added: wnd_get_owner() API to get module that owns windows a window added: !bang redirection to ls_thread fixed: start stage 1/x message was being skipped changed: modifed LICENSE.txt a little to help license validity in german court ## note: to reply to the mailing list, you may have to use "Reply All" because sourceforge might not set the "Reply-To" field to the list address. |
|
From: Mudiaga O. <ob...@us...> - 2002-05-07 00:02:29
|
Wow!! pavel, you're a bug god!
I looked at this and it seems like LSExecute() is broken ... and I didn't=
even notice because I disabled running startup items in
step.rc :-(
It is probaby because of quoting....
or I've added or removed one shell32 call too many...
Now which one was it... I'll have to wait for tomorrow...
Locating the bug:
If you look at the very top of the file
=2E\lsexsh32\shrunner.c you see:
/*
* fixme - parse out argcs
*/
static void do_exec(char * cmd_line)
{
LSExecute(NULL, cmd_line, 0);
}
Can you add
ls_log("exec", LOG_DEBUG, 0, "Running startup command %s",
cmd_line);
before LSExecute to see what that shexsh32.dll is actually calling LSExec=
ute. It=20
seems to be win2k's shell32.dll that isn't doing the exec...
If retro doesn get to that stage, it should say:
"can't enumerate directory entries for ..." in the log file.
Pavel Vitis wrote:
> RS build 0.0.5.10 doesn't run User/Common startup groups items for me=
=2E
>
> I have Win2K SP1 and my startup folder is (Czech edition):
>
> "C:\Documents and Settings\vitis\Nab=EDdka Start\Programy\Po spu=B9t=EC=
n=ED"
>
> And common startup folder is:
>
> "C:\Documents and Settings\All Users.WINNT\Nab=EDdka Start\Programy\P=
o spu=B9t=ECn=ED"
>
> !StartupRun bang doesn't load them too.
>
> All other startup items are run successfuly.
> I didn't find any error/info messages in log about failing of startup=
> loader.
>
> pavel
|
|
From: Pavel V. <pv...@se...> - 2002-05-06 23:11:13
|
RS build 0.0.5.10 doesn't run User/Common startup groups items for me. I have Win2K SP1 and my startup folder is (Czech edition): "C:\Documents and Settings\vitis\Nabídka Start\Programy\Po spuštění" And common startup folder is: "C:\Documents and Settings\All Users.WINNT\Nabídka Start\Programy\Po spuštění" !StartupRun bang doesn't load them too. All other startup items are run successfuly. I didn't find any error/info messages in log about failing of startup loader. pavel --- Pavel Vitis mailto:pav...@se... http://come.to/lsg/ |
|
From: Mudiaga O. <ob...@us...> - 2002-05-06 22:35:23
|
> The problem is, from my point of view, that lot of modules uses > LCOpen(NULL) to load the step.rc for processing with LCReadNextConfig, > etc. Right. When you do this, step.rc is not re-read, but cached values are used. If you change step.rc, you must recycle. > FILE *f = LCOpen(steprc); Just in case... Note that this "FILE *" is not the libc FILE pointer but a "handle"... you may not use it with ANSI f* functions... > Conclusion: I mean that if step.rc file has been found successfuly by > retro(litestep)-core in the beginning, it should be able to open it > again by calling LCOpen(NULL) in the code. This is true and it works for me... retrostep even internally makes this call to get the LoadModule entries. I can't think of a reason why it doesn't work for you. With what module are you having this problem? ~Mudi |
|
From: Pavel V. <pv...@se...> - 2002-05-06 22:22:50
|
>>Comment By: Mudiaga Obada (obada) > Date: 2002-05-06 23:31 > Message: > Logged In: YES > user_id=223361 > In retro, $LitestepDir$ is userdefinable, and sometimes > auto-detected in parent directory. If there is no step.rc in > $ls.dir$. > Look at the Retrostep log. It tells you where it expects to > find step.rc. I have set in step.rc: LitestepDir c:\litestep\ The problem is, from my point of view, that lot of modules uses LCOpen(NULL) to load the step.rc for processing with LCReadNextConfig, etc. It worked for me in LS and pLS, so it seems like classical compatibility problem. I used steprc parameter that's passed into initModuleEx for opening step.rc, which worked well in most cases: FILE *f = LCOpen(steprc); , but in some older builds of LS or pLS (honestly i don't remember that exactly) this didn't worked. So I found that easiest and most compatible way for module is to use LCOpen(NULL). Since it doesn't work in Retro 0.0.5.10 as I learned in couple of my modules, I had to go through and change it to: FILE *f = LCOpen(steprc); if (!f) f = LCOpen(NULL); Now it works in Retro and in LS, pLS too. Conclusion: I mean that if step.rc file has been found successfuly by retro(litestep)-core in the beginning, it should be able to open it again by calling LCOpen(NULL) in the code. pavel --- Pavel Vitis mailto:pav...@se... http://come.to/lsg/ |
|
From: <no...@so...> - 2002-05-06 21:46:24
|
Bugs item #553008, was opened at 2002-05-06 22:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553008&group_id=44038 Category: compatibility (compat) Group: None Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Win+R hotkey fail to register Initial Comment: Retrostep build 0.0.5.10 fails to register Win+R hotkey. Tested with hotkey.dll and jkey.dll. Litestep, PureLS and older Retrostep builds successfuly registers this hotkey. Using this simple step.rc for testing: ---- LoadModule C:\LITESTEP\jKey.dll jKeyUseHotkeyDef jKeyVKTable "c:\litestep\vk104.txt" ;jKeyNoWarn *hotkey Win R !about *hotkey Win C !recycle ---- ---------------------------------------------------------------------- >Comment By: Mudiaga Obada (obada) Date: 2002-05-06 23:46 Message: Logged In: YES user_id=223361 Fixed: Now default hotkeys are registerd after modules modules have had their chance to register what ever the user says, and not before. It was a bad feature... because the user expects us to work like in litestep with same config. Thanks for reporting this. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-06 23:11 Message: Logged In: NO Maybe yes, maybe not. ;) That's your choice. I would prefer to be able to bind that hotkey in some way since I don't use that way to display Run dialog. I'm using Win2k. I do Ctrl+Shift+Esc and "New task..." if needed in emergency. ---------------------------------------------------------------------- Comment By: Mudiaga Obada (obada) Date: 2002-05-06 22:58 Message: Logged In: YES user_id=223361 This is a feature. It is handled by retro. Please the the ChangeLog file distributed with the source. Rational: The idea is that Win+R should always be bound to a Run dialog. So that all users can get consistent behaviour for frequently used keys. IMO, somethings are best left not customizable... LSDistro did this right - stupid distros bind keys differently from explorer. The LS community should work in standardizing certain keys... Should this feature be removed? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553008&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:31:27
|
Bugs item #553027, was opened at 2002-05-06 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553027&group_id=44038 Category: compatibility (compat) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: LSAPI LCOpen(NULL) doesn't open step.rc Initial Comment: Using LSAPI function LCOpen with parameter NULL should open step.rc in default location (I just suppose that, since it's not defined exactly). It's not working in Retro 0.0.5.10. This code works well for LS and pLS: f = LCOpen(NULL); For Retro, it should be changed to: // This line will take effect in LS & pLS f = LCOpen(NULL); if (!f) // This one in Retrostep f = LCOpen(steprc); ---------------------------------------------------------------------- >Comment By: Mudiaga Obada (obada) Date: 2002-05-06 23:31 Message: Logged In: YES user_id=223361 In retro, $LitestepDir$ is userdefinable, and sometimes auto-detected in parent directory. If there is no step.rc in $ls.dir$. Look at the Retrostep log. It tells you where it expects to find step.rc. note: Please consider joining the -devel mailing list so we can discuss such things before filling a bug. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553027&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:20:33
|
Bugs item #553027, was opened at 2002-05-06 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553027&group_id=44038 Category: compatibility (compat) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: LSAPI LCOpen(NULL) doesn't open step.rc Initial Comment: Using LSAPI function LCOpen with parameter NULL should open step.rc in default location (I just suppose that, since it's not defined exactly). It's not working in Retro 0.0.5.10. This code works well for LS and pLS: f = LCOpen(NULL); For Retro, it should be changed to: // This line will take effect in LS & pLS f = LCOpen(NULL); if (!f) // This one in Retrostep f = LCOpen(steprc); ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553027&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:16:21
|
Bugs item #553017, was opened at 2002-05-06 23:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553017&group_id=44038 Category: settings (rc) Group: None >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Win+R hotkey fail to register Initial Comment: Retrostep build 0.0.5.10 fails to register Win+R hotkey. Tested with hotkey.dll and jkey.dll. Litestep, PureLS and older Retrostep builds successfuly registers this hotkey. Using this simple step.rc for testing: ---- LoadModule C:\LITESTEP\jKey.dll jKeyUseHotkeyDef jKeyVKTable "c:\litestep\vk104.txt" ;jKeyNoWarn *hotkey Win R !about *hotkey Win C !recycle ---- ---------------------------------------------------------------------- Comment By: Mudiaga Obada (obada) Date: 2002-05-06 23:15 Message: Logged In: YES user_id=223361 duplicate of #553008 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553017&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:15:54
|
Bugs item #553017, was opened at 2002-05-06 23:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553017&group_id=44038 Category: settings (rc) Group: None Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Win+R hotkey fail to register Initial Comment: Retrostep build 0.0.5.10 fails to register Win+R hotkey. Tested with hotkey.dll and jkey.dll. Litestep, PureLS and older Retrostep builds successfuly registers this hotkey. Using this simple step.rc for testing: ---- LoadModule C:\LITESTEP\jKey.dll jKeyUseHotkeyDef jKeyVKTable "c:\litestep\vk104.txt" ;jKeyNoWarn *hotkey Win R !about *hotkey Win C !recycle ---- ---------------------------------------------------------------------- >Comment By: Mudiaga Obada (obada) Date: 2002-05-06 23:15 Message: Logged In: YES user_id=223361 duplicate of #553008 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553017&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:14:40
|
Bugs item #553016, was opened at 2002-05-06 23:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553016&group_id=44038 >Category: other Group: None >Status: Pending >Resolution: Later >Priority: 2 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: !none bang handler Initial Comment: This info message can be found in 0.0.5.10 about-box- log: rs[bang] i No bang command handler available for '!NONE' Since !none bang is used in some setups to reference 'empty-bang', shouldn't the handler be available in LS core for that bang? ---------------------------------------------------------------------- >Comment By: Mudiaga Obada (obada) Date: 2002-05-06 23:14 Message: Logged In: YES user_id=223361 true... i was going to remove this unveccessary noise... Need to add dummy handler for "!none"... (can be overwriten by modules if they wish...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553016&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:11:25
|
Bugs item #553003, was opened at 2002-05-06 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553003&group_id=44038 Category: compatibility (compat) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lsapi match() is case sensitive Initial Comment: LSAPI function match() in Retrostep seems to be case sensitive, in opposite to Litestep's which is case insensitive. Code: match("*\OPERA.EXE", "c:\opera\opera.exe") will return false. Tested on build 0.0.5.10. ---------------------------------------------------------------------- >Comment By: Mudiaga Obada (obada) Date: 2002-05-06 23:11 Message: Logged In: YES user_id=223361 Has been modifed to be case insensitive. Will be in next release. Thanks. Took the code unmodifed from the public domain. The version used in litestep was modifed and I wasn't aware of that. (So much for stealing ls code - if public domain code wasn't taken from litestep source, why would other code from have been taken? - o well, there's no cure for stupidity) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553003&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:11:17
|
Bugs item #553008, was opened at 2002-05-06 13:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553008&group_id=44038 Category: compatibility (compat) Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Win+R hotkey fail to register Initial Comment: Retrostep build 0.0.5.10 fails to register Win+R hotkey. Tested with hotkey.dll and jkey.dll. Litestep, PureLS and older Retrostep builds successfuly registers this hotkey. Using this simple step.rc for testing: ---- LoadModule C:\LITESTEP\jKey.dll jKeyUseHotkeyDef jKeyVKTable "c:\litestep\vk104.txt" ;jKeyNoWarn *hotkey Win R !about *hotkey Win C !recycle ---- ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-06 14:11 Message: Logged In: NO Maybe yes, maybe not. ;) That's your choice. I would prefer to be able to bind that hotkey in some way since I don't use that way to display Run dialog. I'm using Win2k. I do Ctrl+Shift+Esc and "New task..." if needed in emergency. ---------------------------------------------------------------------- Comment By: Mudiaga Obada (obada) Date: 2002-05-06 13:58 Message: Logged In: YES user_id=223361 This is a feature. It is handled by retro. Please the the ChangeLog file distributed with the source. Rational: The idea is that Win+R should always be bound to a Run dialog. So that all users can get consistent behaviour for frequently used keys. IMO, somethings are best left not customizable... LSDistro did this right - stupid distros bind keys differently from explorer. The LS community should work in standardizing certain keys... Should this feature be removed? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553008&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:06:54
|
Bugs item #553017, was opened at 2002-05-06 14:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553017&group_id=44038 Category: settings (rc) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Win+R hotkey fail to register Initial Comment: Retrostep build 0.0.5.10 fails to register Win+R hotkey. Tested with hotkey.dll and jkey.dll. Litestep, PureLS and older Retrostep builds successfuly registers this hotkey. Using this simple step.rc for testing: ---- LoadModule C:\LITESTEP\jKey.dll jKeyUseHotkeyDef jKeyVKTable "c:\litestep\vk104.txt" ;jKeyNoWarn *hotkey Win R !about *hotkey Win C !recycle ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553017&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 21:06:27
|
Bugs item #553016, was opened at 2002-05-06 14:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553016&group_id=44038 Category: compatibility (compat) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: !none bang handler Initial Comment: This info message can be found in 0.0.5.10 about-box- log: rs[bang] i No bang command handler available for '!NONE' Since !none bang is used in some setups to reference 'empty-bang', shouldn't the handler be available in LS core for that bang? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553016&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 20:58:05
|
Bugs item #553008, was opened at 2002-05-06 22:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553008&group_id=44038 >Category: compatibility (compat) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Win+R hotkey fail to register Initial Comment: Retrostep build 0.0.5.10 fails to register Win+R hotkey. Tested with hotkey.dll and jkey.dll. Litestep, PureLS and older Retrostep builds successfuly registers this hotkey. Using this simple step.rc for testing: ---- LoadModule C:\LITESTEP\jKey.dll jKeyUseHotkeyDef jKeyVKTable "c:\litestep\vk104.txt" ;jKeyNoWarn *hotkey Win R !about *hotkey Win C !recycle ---- ---------------------------------------------------------------------- >Comment By: Mudiaga Obada (obada) Date: 2002-05-06 22:58 Message: Logged In: YES user_id=223361 This is a feature. It is handled by retro. Please the the ChangeLog file distributed with the source. Rational: The idea is that Win+R should always be bound to a Run dialog. So that all users can get consistent behaviour for frequently used keys. IMO, somethings are best left not customizable... LSDistro did this right - stupid distros bind keys differently from explorer. The LS community should work in standardizing certain keys... Should this feature be removed? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553008&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 20:49:55
|
Bugs item #553008, was opened at 2002-05-06 13:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553008&group_id=44038 Category: settings (rc) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Win+R hotkey fail to register Initial Comment: Retrostep build 0.0.5.10 fails to register Win+R hotkey. Tested with hotkey.dll and jkey.dll. Litestep, PureLS and older Retrostep builds successfuly registers this hotkey. Using this simple step.rc for testing: ---- LoadModule C:\LITESTEP\jKey.dll jKeyUseHotkeyDef jKeyVKTable "c:\litestep\vk104.txt" ;jKeyNoWarn *hotkey Win R !about *hotkey Win C !recycle ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553008&group_id=44038 |
|
From: <no...@so...> - 2002-05-06 20:37:30
|
Bugs item #553003, was opened at 2002-05-06 13:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553003&group_id=44038 Category: compatibility (compat) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lsapi match() is case sensitive Initial Comment: LSAPI function match() in Retrostep seems to be case sensitive, in opposite to Litestep's which is case insensitive. Code: match("*\OPERA.EXE", "c:\opera\opera.exe") will return false. Tested on build 0.0.5.10. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=553003&group_id=44038 |
|
From: <no...@so...> - 2002-02-27 12:06:44
|
Bugs item #522505, was opened at 2002-02-25 08:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=522505&group_id=44038 Category: compatibility (compat) Group: generic Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Missing procedure entry point Initial Comment: After starting version 0.0.1.5 retrostep.exe, message is shown: "Entry point of _LSGetImagePath@8 cannot be found in lsapi.dll" and then it crash. I have Windows 2000 SP1. All files in c:\retro\ I have this setting in step.rc: realStepRC "c:\litestep\step.rc" realStepOK 1 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-27 04:06 Message: Logged In: NO This error comes from your precompiled binary that i downloaded. Unfortunately the log file is empty, indeed. ---------------------------------------------------------------------- Comment By: Mudiaga Obada (obada) Date: 2002-02-26 09:15 Message: Logged In: YES user_id=223361 The _LSGet*@8 bug is due to the automatic generation of the .def files not treating stdcall exports right. If you compile with MSC using the IDE or without a .def file, you're fine. gmake build has been extended to handle the stdcall APIs in lsapi. next release will be ok. As for crashing, i do not think that has anything to do with _LSGet*@8. I will need to see the log file... hmm... silly: you'll have to goto %TEMP% (in explorer) and look for the newest file that starts with 'ls' something like 'lsl103.tmp'. That would say probably be empty though because log writes are buffered... next version will fix that too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=522505&group_id=44038 |
|
From: <no...@so...> - 2002-02-26 17:15:42
|
Bugs item #522505, was opened at 2002-02-25 08:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=522505&group_id=44038 Category: compatibility (compat) Group: generic >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Missing procedure entry point Initial Comment: After starting version 0.0.1.5 retrostep.exe, message is shown: "Entry point of _LSGetImagePath@8 cannot be found in lsapi.dll" and then it crash. I have Windows 2000 SP1. All files in c:\retro\ I have this setting in step.rc: realStepRC "c:\litestep\step.rc" realStepOK 1 ---------------------------------------------------------------------- >Comment By: Mudiaga Obada (obada) Date: 2002-02-26 09:15 Message: Logged In: YES user_id=223361 The _LSGet*@8 bug is due to the automatic generation of the .def files not treating stdcall exports right. If you compile with MSC using the IDE or without a .def file, you're fine. gmake build has been extended to handle the stdcall APIs in lsapi. next release will be ok. As for crashing, i do not think that has anything to do with _LSGet*@8. I will need to see the log file... hmm... silly: you'll have to goto %TEMP% (in explorer) and look for the newest file that starts with 'ls' something like 'lsl103.tmp'. That would say probably be empty though because log writes are buffered... next version will fix that too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=522505&group_id=44038 |
|
From: <no...@so...> - 2002-02-25 16:24:28
|
Bugs item #522505, was opened at 2002-02-25 08:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=522505&group_id=44038 Category: compatibility (compat) Group: generic Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Missing procedure entry point Initial Comment: After starting version 0.0.1.5 retrostep.exe, message is shown: "Entry point of _LSGetImagePath@8 cannot be found in lsapi.dll" and then it crash. I have Windows 2000 SP1. All files in c:\retro\ I have this setting in step.rc: realStepRC "c:\litestep\step.rc" realStepOK 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=438236&aid=522505&group_id=44038 |
|
From: Mudiaga O. <ob...@in...> - 2002-01-30 22:10:41
|
I'm not sure I understand what exactly Nexter meant but all the same...
> Okay, from what I've seen so far, you're talking about a function that
> basically replaces the version info structure that is a native
> part of all
> windows executables/libraries - and seldom used by LS modules.
Not quiet... I think it's only in binaries that put it in
their resource file (probably why seldom used by LS modules).
It's another idea to use the same data structures, but doing so
doesn't make things any simpler - neither for ls nor mods - it
requires modules to use resources (or create complex data)
which still needs to be "parsed" by ls... Surely not easier than
Maduin's LMMODULEINFO suggestion but more flexible.
Again, it should be as simple as posible for module writers to
present their about info - just a simple text string.
One shouldn't have to look up any reference or header file.
Just know the right field names.
> As a lazy (ex?)coder, I think reinventing the wheel isn't quite
> justifiable
> unless the existing weel happens to be square.
mod_ctl("about") is just like SMTP (email) headers which is
about 30 yaers old and it still kicking - it isn't reinventing.
... but ignoring the native windows version info infrastructure
is a good thing - that thing happens not to be a wheel, but a
rocket engine. I doubt anybody would be able to use without
looking up the PSDK 5 times or example code 2 times.
I like avoiding the PSDK where I can...
/*
* it's so simple, i have to add
* a complete C implementation
*/
DLLEXPORT const char *
mod_ctl(const char * cmd, const char * arg, char * not_used)
{
if (strcmp(cmd, "about") == 0) {
if (arg == NULL) {
return "MODULE_SIGNATURE:\n" "author: somebody\n" "version: 1.1";
}
}
return NULL;
}
If you still don't like it yet, you brobably never will...
~Mudi (wondering what happened to all the module coders...)
|
|
From: Mudiaga O. <ob...@in...> - 2002-01-28 21:41:08
|
[Opps! I'll just resend this...] Here some rational: > but I disagree with making a single do-everything function. The single do-everything function keeps function prototypes=20 as well as data structures out of peoples heads. The functions that go though it will only be those where=20 the overhead is not a problem. It also simplifies the process of adding extensions to modules, such as querring specific functionality, signaling a module of specific event,..., without requiring Litestep support. (modules can export 50 functions if they wish, but that's=20 one of the things this is meant to avoid) > All we need is a simple GetModuleInfo function that fills in > a LSMODULEINFO struct. Just as easy for the mod coders Except your caller is calling from pascal or some other lang + the text format avoids issues like initializing unused fields, and won't require LSMODULEINFOEX and LSMODULEINFOEX2 in the=20 future.=20 + the text format is extensible (as in XML) + agreeing on using (markup) text format is easier that=20 aggreeing on what goes into LSMODULEINFO and what not. =20 ~Mudi |
|
From: Mudiaga O. <ob...@in...> - 2002-01-28 21:24:50
|
Here some rational: > but I disagree with making a single do-everything function. The single do-everything function keeps function prototypes as well as data structures out of peoples heads. The functions that go though it will only be those where the overhead is not a problem. It also simplifies the process of adding extensions to modules, such as querring specific functionality, signaling a module of specific event,..., without requiring Litestep support. (modules can export 50 functions if they wish, but that's one of the things this is meant to avoid) > All we need is a simple GetModuleInfo function that fills in > a LSMODULEINFO struct. Just as easy for the mod coders Except your caller is calling from pascal or some other lang + the text format avoids issues like initializing unused fields, and won't require LSMODULEINFOEX and LSMODULEINFOEX2 in the future. + the text format is extensible (as in XML) + agreeing on using (markup) text format is easier that aggreeing on what goes into LSMODULEINFO and what not. ~Mudi |
|
From: Kevin S. <ksc...@ke...> - 2002-01-28 18:30:36
|
I agree with the basic idea of having modules provide info in a structured way without the need to load the module -- but I disagree with making a single do-everything function. All we need is a simple GetModuleInfo function that fills in a LSMODULEINFO struct. Just as easy for the mod coders and doesn't require the shell parse the output. -- Maduin ----- Original Message ----- From: "Mudiaga Obada" <ob...@in...> To: "Rs D Ml" <ret...@li...> Cc: "litestep ls ml" <lit...@li...>; "Purels ML" <pu...@li...> Sent: Saturday, January 26, 2002 6:07 AM Subject: [Litestep] dev: mod_ctl: kudos and user sanity I think it would be nice see modules support a new (and optional) function that does a variety of useful things. One example of such a thing is what I think most people would also like to see: - Display useful information about the module. - module name (full name) - authors - maintainer (who built it) - version - release date, build date, etc - module homepage - url-to-go-for-help (email:x@y.org, http://y.org/x/, etc) - license (cough! cough!!) (e.g. "GPL", "BSD", "GPL5 (http: if not OSI approved), ..." This (mostly optional) information need only be made availabe 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 everybodys wishes be taken care of. Of course that does not include those whos needs can never be satisfied. As to this being inappropriate for this list, I have already mentioned to jugg (on purels ML) that litestep-devel@sourcefourge should be created. 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 simple for module writers, but generic and be able to do 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, const char * command_param, char * command_data); + as for the module information mentioned above, Litestep will call it like this, mod_data = mod_ctl("about", NULL, NULL); and a module will do if command == "about" then 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 == "something_else" then 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. 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 litestep and more-or-less compatibles. --------------------------------------------------------------------- Can't Unsubscribe? Check http://desktopian.org/listunsub.html LS List Homepage: http://wuzzle.org/list/litestep.php Get the LS FAQ: http://floach.pimpin.net/lsfaq |
