#exult@irc.freenode.net logs for 19 Feb 2010 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[00:32:27] <Marzo> Ugh
[00:33:00] <Marzo> I wonder who was the brain dead monkey that create the Windows ACL API
[00:33:16] <Marzo> And which underpaid brain dead monkey wrote the documentation
[00:38:14] --> Colourless has joined #exult
[00:38:14] --- ChanServ gives channel operator status to Colourless
[00:42:32] <-- Colourless has left IRC (Ping timeout: 240 seconds)
[00:43:01] --> Colourless has joined #exult
[00:43:01] --- ChanServ gives channel operator status to Colourless
[01:35:20] <-- Dominus1 has left IRC (Quit: Leaving.)
[02:26:30] <Kirben> Windows ACL API? are you looking into writing config/save files issue on later Windows versions?
[03:09:00] <Marzo> Yes
[03:09:45] <Marzo> But there is one MAJOR problem: it needs header files which mingw/msys don't have...
[03:10:26] <Marzo> Naturally, I only found that out AFTER the entire was written and I was trying to compile...
[03:11:01] <Kirben> Not surprised, more recent APIs can take a long time to be added, due to legal issues.
[03:11:18] <Kirben> I would suggest the simple method used by ScummVM:
[03:11:19] <Kirben> http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/trunk/backends/platform/sdl/sdl.cpp?revision=47558&view=markup line 358-399.
[03:11:25] <Marzo> The relevant files are copyright 2000
[03:12:39] <Marzo> Yes, I think I am going to end up going that way
[03:13:21] <Marzo> But not making the mistake of checking the environment variables as they do
[03:16:50] <Marzo> The reason I was trying to determine read/write permissions through ACL was to keep Exult in its semi-portable state, where you can copy on a pendrive and play anywhere, keeping the configuration changes
[03:17:51] <Marzo> But since it is boneheadedly impossible to effectively determine permissions in Windows without digging into ACL API and losing mingw on the way, I guess we will have to take the easier way.
[03:17:56] <Colourless> ACL api is overly complicated
[03:18:49] <Kirben> Couldn't a user still create their own config file, and have that used? I'm assuming it will still check for exult.cfg in executable directory.
[03:18:56] <Marzo> Hence the comments on the "brain dead monkey that designed it" I made earlier
[03:19:11] <Marzo> I will take that route
[03:19:46] <Colourless> the way i'd solve the 'issue' would be to have a setting in the 'default' exult.cfg that tells where exult should be writing.
[03:19:47] <Marzo> [21:46:20] <Marzo> So the basic working steps are: (1) Exult checks for the cfg in the current dir: if present and can read/write, use it; (2) otherwise, check for cfg in new default dir: if present, use it; (3) if we have read-only cwd cfg, but no cfg in user dir, copy it there and use new copy
[03:20:01] <Marzo> That works too
[03:20:17] <Marzo> I was thinking a setting "<portable>" or something
[03:20:36] <Colourless> if the setting hasn't been set we go into 'upgrade' mode where we determine though whatever magic what the it needs to be set to and 'fix up' the current install so its ok
[03:21:07] <Marzo> The problem is the "whatever magic"
[03:21:51] <Marzo> In Windows XP and below, and (I think) in Windows 7, I could just try opening a file for writing in the current dir and see if it fails
[03:22:01] <Colourless> i'm thinking at least part of it should ask the user what they want to do, then tell them if they need to do any OS magic such as fixing file permissions
[03:22:40] <Kirben> (3) Sounds confusing, since that would mean two config files (how does user know which one is been used?). Wouldn't an error or warning be better in that case?
[03:22:43] <Colourless> though part of me thinks that requring the user to do something complicated like adjusting file permissions in windows is asking for big trouble
[03:23:28] <Marzo> Kirben: It will be a problem any way it is done
[03:24:52] <Marzo> We can't delete the file or edit it any way if we only have read access
[03:25:23] <Marzo> But the reason I had stated (3) is that the user will presumably set the correct paths during setup
[03:25:52] <Marzo> This way, it would at least preserve those settings
[03:25:58] <Colourless> the real issue is there is per user, and per machine settings
[03:26:06] <Marzo> Aye
[03:26:06] <Colourless> paths to the games are per machine
[03:26:10] <Colourless> save games are per user
[03:26:22] <Colourless> other game perferences are alsp per user
[03:26:40] <Colourless> normal games don't have this issue cause data is always with the exe
[03:28:00] <Marzo> Actually, a case could be made for leaving even the path settings per user
[03:28:49] <Marzo> It wouldn't be the case in most computers, but really shared computers could see different users installing the games independently, without even being aware the others had done it
[03:28:54] <Colourless> if we were to allow exult to change the path settings to add new games or something globally, it would be possible for force a UAC prompt and elevate to Administrator for that operation
[03:28:58] <Marzo> (this is theoretical, of course)
[03:30:35] <Marzo> From what I read in the link shell extension (http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html) description of how they worked with UAC, I would prefer to avoid it :-)
[03:33:05] <Marzo> Of course, since this is a new release, we could break that bit of compatibility
[03:33:41] <Marzo> Make Exult completely consistent in its handling of exult.cfg, savegames and gamedat across all OSes
[03:34:12] <Marzo> That is, write exult.cfg to a user writable directory and be done with it
[03:34:51] <Marzo> Perhaps with an upgrade notice for the installer, which could move the cfg to the correct directory
[03:35:09] <Marzo> Hm
[03:35:30] <Kirben> How can path be kept consistent for all Windows OS? when Windows 9x/ME doesn't offer the same kind of user profile support.
[03:36:01] <Marzo> Win9x/Me is indeed a bugger
[03:36:28] <Marzo> Maybe *it* could have the data in "My Documents/My Games" or somesuch
[03:37:13] <Marzo> (at least "My Documents" is guaranteed to exist..."
[03:37:54] <Kirben> Are you sure? I thought the whole My* was added with Internet Explorer (3.0?)
[03:38:00] <Marzo> Or maybe have Win9x/me work as it does already, but 2000 and up work correctly
[03:38:17] <Marzo> No, it was right from the first release of Win95
[03:38:42] <Marzo> The better ways to *get* the damned path were added with IE3
[03:38:59] <Marzo> s/with/starting with
[03:39:15] --> Malignant_Manor has joined #exult
[03:40:49] <Marzo> Wow: I hadn't noticed until now I had 40 tabs dealing with ACL open in Firefox
[03:42:12] <Marzo> Hm. According to Wikipedia, the "My Documents" folder was introduced in Win95 OEM SR2
[03:42:41] <Marzo> I guess my memory was wrong on the subject after all :-)
[03:42:49] <Malignant_Manor> Why not just have it look for exult.cfg in the executable directory for all Windows systems to override the multiple user file system?
[03:42:51] <Kirben> Which would have been, when Internet Explorer 3.x was bundled.
[03:43:53] <Malignant_Manor> Well, instead of screwing over the system in place now.
[03:44:04] <Marzo> Malignant_Manor: you mean looking into the exe dir for the game paths only and looking for everything else in the user dir?
[03:44:36] <Marzo> If so, it is more or less what Colourless suggested
[03:45:24] <Marzo> But the issue is that an user could install Exult with the game data in a folder which *he* has read/write access to but the other users don't
[03:45:32] <Malignant_Manor> Well, I'd rather have all information be able to be used.
[03:45:32] <Malignant_Manor> I guess, it really isn't a problem unless you have multiple installations.
[03:45:48] <Marzo> For example, he could encrypt his user profile
[03:46:14] <Marzo> (I have seen it happen -- not with Exult, though)
[03:46:43] <Marzo> Anyone else would not be able to use the game data
[03:47:35] <Marzo> I am thinking that the installer should simply move the cfg to the correct location if Exult is installed to Program Files
[03:47:38] <Marzo> Hm
[03:47:44] <Malignant_Manor> They just wouldn't be able to alter it, they could still use it.
[03:48:18] <Malignant_Manor> This would only be if someone purposely placed the cfg file there.
[03:48:42] <Marzo> If the profile is encrypted, and the game data is there, it is unusable by anyone else but the person that encrypted it
[03:49:07] <Colourless> if something is in someones profile dir it can only be assumed to be private
[03:49:13] <Marzo> Aye
[03:49:25] <Malignant_Manor> So they couldn't use Exult anyway.
[03:50:02] <Marzo> My point was with Exult installed in program files but U7 and SI to the user's profile
[03:50:20] <Marzo> s/to/at
[03:50:28] <Marzo> But enough worst cases
[03:51:48] <Malignant_Manor> How I explained is how DosBox does it, but users can be stupid enough to screw it up.
[03:53:38] <Malignant_Manor> All this, because Windows took forever to convert to multiple users by default.
[03:54:01] <Marzo> Whichever way we try to deal with the problem, someone, somewhere, will have a problem with how it was done
[03:54:12] <Marzo> We might as well pick an option and stick with it
[03:54:44] <Marzo> So how about: Win9x/Me: Exult looks in current path and we are done
[03:54:58] <Marzo> Win 2000 and up: store in user profile
[03:55:11] <Marzo> This is for both, cfg and savegames/gamedat
[03:56:05] <Marzo> (and screenshots, can't forget about those)
[03:56:19] <Kirben> Sounds ok, but how are you going to get the user profile? if not using enviromental variables.
[03:56:37] <Marzo> There is a solution at the patch tracker already
[03:57:01] <Malignant_Manor> That's fine except for user stupidity/ignorance.
[03:57:05] <Marzo> That is: using SHGetFolderPath
[03:57:31] <Marzo> Maybe even upgrading to the new API in Vista and 7
[03:57:52] <Marzo> In all cases, using dynamic runtime linking to avoid problems
[04:00:00] <Marzo> Hm. Using SHGetFolderPath has the benefit that it in Win95 and plain Win98 with IE5 and with all versions since Win98SE
[04:00:53] <Marzo> s/that it in/that it works in
[04:01:52] <Kirben> Yes, but user is forced to install IE5, if they don't have it. I can't seem to locate a separate shell32 redist/update.
[04:01:55] <Marzo> I don't know of anyone that uses Win9x without at least IE6, so it could end up working on almost all systems
[04:02:19] <Marzo> I can state without fear of error that there is no shell32 redist
[04:03:05] <Marzo> If there were, any badly designed installer could overwrite shell32.dll with very bad consequences
[04:03:25] <Marzo> Because of dynamic linking, there is no issue
[04:03:26] <-- julien has left IRC (Ping timeout: 272 seconds)
[04:04:01] <Marzo> HMODULE hLib = LoadLibrary("shell32.dll"); SHGetFolderPathFunc proc = (SHGetFolderPathFunc)GetProcAddress(hLib, "SHGetFolderPathA");
[04:04:09] --> julien has joined #exult
[04:04:33] <Marzo> Then if "proc == NULLL", fallback to old behavior
[04:04:40] <Marzo> s/NULLL/NULL
[04:05:26] <Marzo> This could be done *once*, instead of every time as the patch in the tracker does, which would reduce overhead
[04:05:55] <Marzo> Then, if on Vista or 7, check for SHGetKnownFolderPath instead
[04:05:58] <Colourless> just store the PFC gobally with a bool to indicate if its been loaded or not
[04:06:08] <Marzo> Indeed
[04:06:25] <Marzo> I was thinking of that, exactly
[04:06:54] <Colourless> just curious, anyone tried running exult on win95 lately? does it even work,
[04:07:03] <Marzo> I have no idea
[04:07:18] <Marzo> I know of someone that runs on Win98, with ES
[04:08:02] <Marzo> But even when I was working on ES support on these ancient OSes, I only went as far as putting Win98 in a virtual machine
[04:08:36] <Marzo> (not that I think my set of Win95 *floppies* would work anymore...)
[04:09:02] <Kirben> Yes, would be interesting to know if Exult still works on Windows 95, SDL should be fine at least.
[04:09:33] <Malignant_Manor> I could uninstall Win98 SE upgrade (and hope things are going to play nice when I update again)
[04:10:11] <Marzo> It would be better to test in a VM
[04:10:26] <Marzo> It is the least destructive option
[04:10:44] <Marzo> (particularly in modern hardware...)
[04:11:04] <Malignant_Manor> Hopefully mine isn't bound to hardware.
[04:11:32] <Marzo> I was thinking on Win95 in modern hardware, and its lack of driver support
[04:11:54] <Marzo> Even XP has problems with some harddisks nowadays
[04:12:59] <Colourless> win95 wont run on modern hardware cause of timer issues
[04:13:11] <Malignant_Manor> I'd have to test some other day.
[04:15:12] <Kirben> Yes, need XP SP1 at least for larger hard drives, but extra drivers can easily be added during install, if required.
[04:16:08] <Marzo> Some things just won't work even with XP SP3
[04:16:39] <Marzo> The laptop I am working on right now has a hard drive that would die a couple of months after XP is working
[04:17:33] <Marzo> It has a "feature" that Linux, Vista and W7 can manage correctly, but which causes rapid wear in XP or lower
[04:17:48] <Kirben> That sounds unusual, there is no reason hard disks should fail to work in XP.
[04:18:23] <Kirben> What feature? it is a SDD drive?
[04:21:21] <Marzo> It is a form of shock protection
[04:21:52] <Marzo> Even Ubuntu before 8.10 suffered with this "feature"
[04:22:06] <Marzo> But there was a workaround to disable it at least
[04:22:18] <Marzo> In XP, you are just waiting for the HD to fail
[04:23:00] <Marzo> (not that there were any kind of drivers for XP anyway -- it is impossible, for example, to find a graphics driver for this laptop for XP)
[04:23:33] <Marzo> It was a big part of the reason why I moved to Linux :-)
[04:29:50] <Malignant_Manor> I'm not liking messing with the audio volume. I've got it to where I know I can set ogg music, wave sfx, and wave speech. I'm not sure about midi, I think Windows may have issues and will need to switch to Linux to test.
[04:30:29] <Malignant_Manor> It would be nice to have menu settable volume levels.
[04:30:48] <Marzo> I was thinking of adding some form of sliders for that
[04:30:59] <Marzo> But it will be delayed until after the release
[04:31:37] <Malignant_Manor> Wouldn't think it would be hard (except possibly midi).
[04:31:54] <Marzo> "Feature freeze" :-)
[04:32:10] <Colourless> midi not difficult to implement
[04:32:38] <Colourless> just apply a multiplier to the velocity of the notes being played
[04:32:54] <Malignant_Manor> Mix_Volume is currently used for sfx, but I needed to change to Mix_VolumeChunk.
[04:33:28] <Colourless> in some cases though there might be bad interactions between various volume levels
[04:34:13] <Colourless> separate voice, music and effects is all you should have
[04:34:20] <Colourless> a global 'master' volume control is asking for trouble
[04:37:34] <Marzo> Agreed
[04:43:24] <Malignant_Manor> Do you have a quick example of where/how the midi would be changed for volume?
[04:57:18] <Malignant_Manor> Nevermind, I found it.
[05:22:00] <Marzo> Well, good night to all, I can barely keep my eyes open anymore
[05:22:18] <Malignant_Manor> goodnight
[05:26:49] <-- Marzo has left IRC (Ping timeout: 264 seconds)
[06:06:46] <-- Malignant_Manor has left IRC (Ping timeout: 265 seconds)
[08:59:37] --> Dominus has joined #exult
[08:59:37] --- ChanServ gives channel operator status to Dominus
[09:01:11] <Dominus> food for thought, we also need to handle screenshot location and stdout/stderr.txt location (if we can set those)
[12:15:50] <-- Colourless has left IRC (Ping timeout: 240 seconds)
[12:19:58] --> Colourless has joined #exult
[12:19:58] --- ChanServ gives channel operator status to Colourless
[12:50:31] --> CorvusE has joined #exult
[12:51:14] <-- CorvusE has left IRC (Client Quit)
[12:52:51] --> CorvusE has joined #exult
[12:55:50] <-- Kirben has left IRC ()
[13:17:33] <-- Colourless has left IRC (Quit: casts improved invisibility)
[13:36:35] --> Marzo has joined #exult
[13:57:43] <-- Dominus has left IRC (Quit: Leaving.)
[14:06:05] <Marzo> Dominus: There are 3 ways to handle stdout/stderr redirection
[14:06:56] <Marzo> One is to compile and distribute our own version of SDL.dll compiled without stdout/stderr redirection; we would then add our own code for it
[14:08:50] <Marzo> Next, we could include SDL_win32_main.c directly in Exult, instead of linking to libSDLmain, and either alter it to redirect to where we want or disable redirection and let Exult decide where to redirect to
[14:09:51] <Marzo> Third is a hack, apparently discovered by the Nuvie folks, in which defining "main" in a source file that does not include SDL.h prevents the SDL main function from being called
[14:10:36] <Marzo> I am leaning towards #2: having SDL_win32_main.c with stdout/stderr disabled and letting Exult do it whichever way it wants
[14:10:51] <Marzo> Anyways, I hope you check the log when you get here
[15:55:37] --> Dominus has joined #exult
[15:55:37] --- ChanServ gives channel operator status to Dominus
[16:12:48] <-- CorvusE has left IRC (Quit: Aaaand, I'm out.)
[16:18:44] --> CorvusE has joined #exult
[16:20:14] * Marzo points Dominus to the log
[16:20:24] <Dominus> hey marzo, yes, I read it
[16:20:39] <Marzo> Turns out it is easier said than done
[16:20:46] <Dominus> as for stdout/err, whatever you deem best
[16:20:58] <Dominus> as for the stupid windows thing, I read it
[16:21:00] <Dominus> bah
[16:23:00] <Dominus> it came to me that testing write access could maybe backfire anyway, since Vista/W7 DO allow writing to the folder by redirecting to a folder in the userspace
[16:23:31] <-- CorvusE has left IRC (Remote host closed the connection)
[16:23:38] <Marzo> Which is why I was trying using the ACL API: I already knew that the naïve test would fail
[16:24:04] <Marzo> I think that W7 actually doesn't redirect anymore, simply preventing the app from working
[16:24:10] <Marzo> But I could be wrong about that
[16:24:12] <Dominus> it does redirect
[16:24:24] <Dominus> I have W7 on a laptop and in a VM
[16:24:38] <Marzo> So you will be the guinea pig then :-)
[16:24:54] <Dominus> only Shadow Chaser the bug/patch reporter had some misterious worst case scenario where that failed :)
[16:25:13] <Dominus> guniea pig…. hooray :)
[16:25:28] <Marzo> I actually found out that SDL 1.2.14 checks SDL_STDIO_REDIRECT env var to determine if it should do redirection
[16:25:44] <Marzo> But by the time we get to exult.cc:main, it is too late to set it
[16:25:53] <Dominus> I just have no working mingw/msys development to compile stuff directly, would need to set that up :)
[16:26:13] <Marzo> Oh, I could put the compiled binaries for you somewhere
[16:26:23] <Dominus> nice :)
[16:26:36] <Marzo> Once I finish it and finish compiling it
[16:27:06] <Marzo> (both of which are annoying propositions because I am developing in one comp and will be compiling on another...)
[16:27:14] --> CorvusE has joined #exult
[16:27:44] <Dominus> ok, will gladly test it. The VM is otherwise setup to use it. I'll see if I can dig up my backup of my Windows development setting...
[16:28:18] <Dominus> As for screenshots, I'd propose another path setting for those in exult.cfg
[16:28:57] <Dominus> under the <disk> tag
[16:29:06] <Marzo> It is a possibility
[16:29:32] <Dominus> I already found it annoying that on os x (and probably linux) it just saves to the home dir
[16:29:39] <Marzo> I was thinking on one of two solutions: (1) Use same folder as base saves/stdout/stderr and stuff; (2) save to "My Pictures"
[16:30:30] <Marzo> But adding an option to the <disk> tag, defaulting to one of those solutions (and to $HOME on OSX/linux/etc), would be ideal
[16:31:25] <Dominus> yes. save to "my pictures/exult" sounds good too
[16:31:43] <Dominus> but maybe people would prefer same folder as saves
[16:32:54] <Dominus> btw. the folder we will choose finally must be well thought out too. I have to check, but the folder dosbox uses for this stuff seems to be hidden normally, so we shoudl avoid this. but I need to check which one that is :)
[16:33:21] <Marzo> We could try literally putting screenshots in the same folder as saves
[16:33:40] <Marzo> This would make screenshots compartmentalized by games/mods
[16:34:15] <Marzo> Or just in the same root (local_appdata\Exult or $HOME/.exult)
[16:34:56] <Dominus> and on the early morning discussion, I also think it's safe to say, that whoever runs w9x these days has the ie3 extensions installed one way or the other. so much software did use this stuff that it should be in the system
[16:35:22] <Dominus> same folder as saves -> compartmentalized by games/mods, sounds best to me
[16:35:48] <Marzo> As it turns out, looking further, for Win95 and Win98 FE, we would have to load another library instead to get the API call to work
[16:36:12] <Marzo> Even 98 SE wouldn't work 100%
[16:36:26] <Marzo> From Me upwards, everything works perfect though
[16:39:01] <Marzo> brb
[16:45:27] <Dominus> ah, too bad. So Shadow Chaser WAS right in some of his claims about the problems for Windows 9x… but couldn't it be possible to just check whether we are on W9x and if we are not doing anything different? :)
[17:08:25] <Marzo> Back
[17:08:36] <Dominus> hmm, I need to make another feature request. When running a release version of Exult, disable the Studio keyboard shortcuts, or did I already make this request? :)
[17:09:48] <Marzo> Disabling the contents of the action functions should do it
[17:10:07] <Marzo> I assume we are not making yet a release version of ES then?
[17:10:35] <Dominus> I just thought about it when answering the latest forum post when I wrote back whether the op is using the latest snapshots
[17:10:49] <Dominus> About releasing ES… I'd say it's your call
[17:11:13] <Marzo> I'd say not yet, no
[17:11:23] <Dominus> good, decision made :)
[17:12:03] <Dominus> BUT I would like to have the current si-fixes and BG-keyring ready for the release :)
[17:12:25] <Dominus> (maybe even have it come preinstalled)
[17:13:08] <Dominus> so, now I have to cook, bbl :)
[18:15:24] <-- CorvusE has left IRC (Remote host closed the connection)
[19:26:28] <-- Dominus has left IRC (Quit: Leaving.)
[22:24:57] --> Kirben has joined #exult
[22:24:57] --- ChanServ gives channel operator status to Kirben
[22:53:14] <Marzo> Kirben: out of curiosity, what version you are using to compile on Windows?
[22:56:21] <Kirben> GCC 4.2.1-dw2
[22:57:02] <Marzo> I am toying with the MinGW official 4.4.0
[22:57:09] <Marzo> Will let you know how it turns out
[22:58:12] <Marzo> (I ask because I already saw a few warnings due to unordered hash maps and sets)
[22:58:54] <Kirben> GCC 4.4.0 is still too buggy, manages to crash too easily.
[23:00:42] <Marzo> Hm. Didn't know that
[23:00:53] <Kirben> Manages to crash doing basic tests in configure script of ScummVM for example.
[23:01:12] <Marzo> So far, I haven't seen any crashes
[23:01:35] <Marzo> But then again, most of my experience with 4.4 is in Ubuntu
[23:02:06] <Kirben> Mingw ports of GCC often have issues.
[23:02:25] <Marzo> Aye
[23:04:08] <Marzo> This version you are using: is it from the MinGW project page or from elsewhere? In there, I see an sjlj version of 4.2.1, al alpha 4.3.0 and the 4.4.0
[23:05:11] <Marzo> (I mean in case I want to switch versions)
[23:07:39] <Kirben> MinGW proect, I can't seem to locate in downloads sections either.
[23:08:15] <Marzo> It would seem that they deprecated that version then, for better or for worse
[23:08:25] <Kirben> I usually try each GCC version as announced on mailing list, testing against all programs I regularly compile.
[23:09:30] <Marzo> Me, I have been letting my MinGW/msys system fall behind for quite a while, as I Ubuntu primarily now for developing
[23:09:38] <Kirben> I wonder why, dwarf2 is the default in later releases.
[23:10:36] <Marzo> I seem to remember it being faster and safer
[23:11:04] <Marzo> And I also seem to remember the issues regarding mixing SJLJ and dwarf-2 being fixed
[23:11:09] <Marzo> But I may be misremembering
[23:54:29] --> Colourless has joined #exult
[23:54:29] --- ChanServ gives channel operator status to Colourless