IRC logs for #opendune on OFTC at 2009-11-04
⏴ go to previous day
00:00:06 <glx> so src/core/strings.h seems good
00:00:34 <TrueBrain> argh, I really should go to bed, but okay:
00:00:49 <TrueBrain> as it is os related, but there might be oses which do not implement it at all ..
00:01:26 <glx> 'os' is probably better yes
00:01:56 <TrueBrain> on one side, yes .. on the other: no :p
00:02:00 <TrueBrain> grr .. I have to sleep on it :)
00:02:10 <TrueBrain> tnx for the input :) Good night!! :)
00:02:52 <TrueBrain> ps: strcmp is C89, stricmp/strcasecmp is not
00:03:16 <glx> so the warning with -ansi is right :)
00:03:27 <TrueBrain> that GCC accepts it is not correct, yes
00:03:47 <TrueBrain> so either we first need to run 'tolower' over the strings (expensive), or just make such wrappers and hope for the best ;)
00:03:58 <glx> it warns about it with -ansi, but it's in crt
00:04:30 <TrueBrain> so okay ... a good night sleep, maybe then I know a bit more what to do with all those questions of today ...
00:04:37 <TrueBrain> (fix bugs yes/no, and where to place OS shit ..)
00:04:47 <TrueBrain> I do not like stdafx.h of OpenTTD ..
00:04:57 <TrueBrain> k: night :) (now for real :p)
00:49:53 *** Guest677 is now known as planetmaker
09:45:34 <TrueBrain> Xaroth: how about this: we now add compile-time #ifdefs or something, which switches OpenDUNE between 2 modes: original and enhanced. Later on, we split the stuff in modules, where they each go in another module?
09:49:15 <DorpsGek> SVN: truebrain (r461) -Add: an 'os' layer for non-C89 compatibility (like strcasecmp)
09:49:26 <TrueBrain> there .. for glx to make mingw and MSVC to work ;)
09:49:51 <Xaroth> that's what I was trying to suggest yesterday :P
09:50:23 <TrueBrain> well, you talked about a const, but that is besides the point :) Last night I tried to find some middle ground which would work what ever route we take after this
09:50:48 <Xaroth> well I defaulted to 'const' because I'm not up-to-date how to fix things like that in C
09:50:56 *** TinoDidriksen has joined #openDune
09:51:08 <TrueBrain> I was joking Xaroth :)
09:51:13 <Xaroth> oh, and re: blog, that should be doable with wordpress
09:51:49 <Xaroth> adding them to a separate category etc
09:51:55 <TrueBrain> that don;t show on the main page?
09:52:19 <TrueBrain> how to call the ifdef .. #ifdef ORIGINAL_MODE ?
09:52:47 <Xaroth> MODE_ORIGINAL / MODE_ENHANCED
09:52:56 <TrueBrain> well one of the two you only need :p
09:53:59 <TrueBrain> so MODE_ENHANCED? :)
09:55:55 <TrueBrain> k, that is decided then :p
09:56:44 <Xaroth> under visibility you can make posts stick to the front page
09:56:52 <Xaroth> I think that means it'll take presedence in front page items
09:58:02 <Xaroth> but the frontpage is said to show the latest posts ..
09:58:09 <Xaroth> so i'm not sure how that'll work with 'idea blogs'
09:58:19 <TrueBrain> maybe another wordpress in blog. or something?
09:58:19 <Xaroth> but tbh, having those blog posts does make the project look more lively
09:58:23 <TrueBrain> or is that a bad idea?
09:58:38 <TrueBrain> that is true, but we should have the first page show 'news' entries only
09:58:50 <TrueBrain> as those posts will be only for people who are interested :)
10:01:07 <Xaroth> I can mod wordpress to show only 1 category
10:02:05 <Xaroth> so, adding a News category for now :P
10:02:12 <TrueBrain> wouldn't that be better, you think?
10:04:07 <TrueBrain> when you visit OpenDUNE for the first time, you want to see key news .. after that, you want to read all the funny stuff :p
10:10:21 <Xaroth> already working on that
10:10:30 <TrueBrain> no rush, just thinking out loud :)
10:15:19 <Xaroth> TrueBrain: how's that?
10:15:31 <Xaroth> pre-alpha temporarily in uncat category
10:15:39 <Xaroth> doesn't show up in frontpage
10:15:43 <Xaroth> does show up in category view
10:15:55 <TrueBrain> ah, like that you mean: how's that? :p
10:16:18 <Xaroth> the fix: <?php if (!in_category('3') && is_home()) continue; ?>
10:17:27 <Xaroth> so, how do you want to name your category
10:17:45 <TrueBrain> I want to blabla about undocumented things I find
10:17:54 <TrueBrain> like how repair works, how scenario load works
10:18:57 <TrueBrain> will blog some tomorrow :)
10:19:22 *** BoekaBart has joined #openDune
10:19:32 <Xaroth> last time i tried to update the theme it fucked up some files
10:19:47 <Xaroth> it moved my background image away
10:19:52 <Xaroth> and restored some mods
10:44:01 <Xaroth> btw, I think both nyer and fibble's icons are clones of the original icon
10:44:10 <Xaroth> I think we're better off using our 'own' icon.
10:45:38 <Xaroth> ofcourse, this was already decide :P
10:45:41 <Xaroth> makes the blow a bit softer :)
10:46:38 <TrueBrain> sometimes, I don't follow people :( :p
10:47:14 <BoekaBart> TrueBrain: what's the reason again, that an 'int 10' or similar call, is expanded to a full funtio where the syscall(0x10) is excecuted? why isn't that simply done in emu_int( .. ) ?
10:47:30 <TrueBrain> emu_int is on software level
10:47:33 <TrueBrain> emu_syscall is hardware level
10:48:15 <Xaroth> sometimes it's best not to follow people ;)
10:48:46 <BoekaBart> still - i'd say the CPU layer should implement this, not the decompiler...
10:49:05 <Xaroth> btw, TrueBrain, any chance of what Skrilax wanted? (full screen support/resizing of sdl window)
10:49:34 <TrueBrain> BoekaBart: not possible, you need something to decompile to the hardware
10:49:40 <TrueBrain> Xaroth: currently, no
10:50:29 <BoekaBart> TrueBrain: but the processor knows what to do when the instruction int10 is reached, right?
10:50:44 <TrueBrain> let me explain again :)
10:50:48 <TrueBrain> when the CPU reads an INT10
10:50:51 <BoekaBart> (the only reason I nag, by the way, is code readability)
10:51:01 <TrueBrain> it looks in the IVT and jumps to that position
10:51:05 <TrueBrain> that is _ALL_ INTs do
10:51:12 <TrueBrain> (oh, and it pushed flags, cs and ip)
10:51:26 <TrueBrain> it does nothing more, nothing less
10:51:36 <TrueBrain> and very vital for normal operations of 16bit applications
10:51:44 <TrueBrain> (software can take over any interrupt at any time)
10:52:04 <TrueBrain> so, at initialization, the IVT is filled with small pieces of code, which make a syscall, which handles hte hardware side of an interrupt
10:52:11 <BoekaBart> exactly - so whouldn't it, for code readability, not be better to implement this once in 'emu_int(..)' cpu instruction, rather than expanding this into "emu_pushf(); emu_flags.inf = 0; emu_push(emu_cs); emu_cs = 0x0070; emu_push(0x0143); f__0070_0080_0005_E27B();" all the time?
10:52:11 <TrueBrain> this, because we do not want to implement the BIOS in the software side
10:52:39 <TrueBrain> for the same reason we do not have: emu_jump(0x1F7, 0x100)
10:52:43 <TrueBrain> we have a static jump there
10:52:50 <TrueBrain> in static compiled, you can NOT HAVE dynamic jumps
10:52:55 <BoekaBart> no I understand that
10:53:06 <BoekaBart> t this _always_ translate to a syscall?
10:53:17 <TrueBrain> but that is not known at that time
10:54:24 <BoekaBart> OK, I see. Then, a comment /*int 10*/ emu_pushf( ..... might help for readability :)
10:54:58 <TrueBrain> as there is no importance anymore which interrupt it was trying to call
10:55:06 <TrueBrain> as it can be used (like overlays) to just call a function
10:55:11 <TrueBrain> only in a slightly more elegant way
10:55:22 <TrueBrain> the syscalls are the 'true' int10 calls
10:56:10 <TrueBrain> Take OpenDUNE, one of the first things we did was define what the interrupts do .. we named all 0070 entries
10:56:18 <BoekaBart> when generating the 0070 fns, that IS known? so the decompiler could generate a 'better' name for those then
10:56:28 <TrueBrain> no, it is not known at that stage
10:56:33 <BoekaBart> ok, so manual labour.
10:56:36 <TrueBrain> for all we know the application put new code over the 0070 data
10:56:48 <TrueBrain> you can't assume anything in decompiling, you can only follow the white rabbit
10:57:01 <TrueBrain> at some point you know stuff .. but this is only when a syscall is read
10:57:13 <TrueBrain> later optimizations can deduce the function, but this is a backtrace process
10:57:19 <TrueBrain> which is currently not supported in any way :)
10:57:46 <TrueBrain> (backtrace optimization means you start somewhere deep in a tree, knowing exactly what it does, and work your way up marking things based on that info)
10:58:10 <TrueBrain> so ints and syscalls really can't be made more pretty at this stage
10:58:51 <TrueBrain> [11:48] <BoekaBart> still - i'd say the CPU layer should implement this, not the decompiler... <- btw, the CPU layer === decompiler, as the decompiler needs to know a lot about the CPU :)
11:00:14 <TrueBrain> further more, you can't just keep a list of where int10 jumps to, as for example int2f jumps one time to point A, the other time to point B
11:01:01 <TrueBrain> short: ints are just like jumps, just it pushed the flags too :)
11:01:25 <TrueBrain> syscalls are not requires in the perfect world, where we would implement the BIOS in the 16bit memory :)
11:01:58 <TrueBrain> (I keep mixing up the s and d ...)
11:05:23 <BoekaBart> TrueBrain: You said that the new JIT would just DO the emu_ calls rather than just-in-time compilation of generated code?
11:05:44 <BoekaBart> That would probably mean, that it runs on win32 too...
11:05:46 <TrueBrain> yes, when looking back, using TCC is silly
11:06:05 <TrueBrain> each node can just call the function in the libemu
11:06:12 <TrueBrain> it will be slower :p
11:06:25 <BoekaBart> so instead of gen_code -> compile -> execute, just gen_code and call the same calls at the same time
11:07:02 <TrueBrain> instead of now: WriteC -> TCC -> Execute, it will be: Execute
11:07:22 <TrueBrain> in the AST, you have something like: add, cmp, ...
11:07:32 <BoekaBart> well the C will be written also, right...
11:07:37 <TrueBrain> normally it writes the C for this, compiles it, executes it, but the nodes can also just execute theirself, and call the next node
11:07:43 <TrueBrain> nope, not in the JIT
11:07:50 <TrueBrain> only at the --static stage
11:07:53 <BoekaBart> ah right, of course, --static does that
11:07:59 <BoekaBart> (you surely type fast...)
11:08:33 <TrueBrain> except the speed of light
11:08:49 <BoekaBart> So, how's that coming along?
11:09:03 <TrueBrain> not; working on OpenDUNE for now :)
11:09:11 <TrueBrain> I need to rewrite the complete ToC :(
11:09:17 <TrueBrain> 200 functions .. no fun :)
11:09:40 <TrueBrain> tons of Execute, WriteC, WritePascal (have to try that), ..
11:10:00 <TrueBrain> although I have found that the ALU commands can get a few shortcuts
11:11:24 <BoekaBart> it sucks that.. stuff where you used to do like memory%d(... you now have to make switches and lot of those, i guess
11:12:29 <BoekaBart> 1 node could write a lot of variations of functions, based on the 'chars / strings' helper fns returned (8, 16, b, w, emu_ah, emu_bx)...
11:12:49 <BoekaBart> now, there will be more switchcasing...
11:13:34 <BoekaBart> well... how do you call set_memory8_or_16 based on smth a helper returns?
11:13:50 <TrueBrain> addwm takes care of that
11:14:10 <BoekaBart> same for outb, outw ...?
11:14:31 <TrueBrain> there is only need for a few wrappers to do the Execute() stuff
11:14:46 <BoekaBart> i mean... how to 'decide' between outb and outw
11:14:53 <TrueBrain> that is in the instruction of course
11:14:58 <TrueBrain> the same way as it is decided now
11:15:02 <BoekaBart> if ( ... ) outb else outw, right?
11:15:16 <BoekaBart> but now it is out%c(...) with input from a helper
11:15:22 <TrueBrain> sorry, you are not always the moest clearest in what you try to say ;)
11:15:31 <BoekaBart> maybe we should talk dutch
11:16:16 <TrueBrain> but yes, every instruction in Execute() gets a small if-cascade
11:16:42 <BoekaBart> so that's all there's to it right, implement Execute() in each node
11:16:44 <TrueBrain> (the memory part is handled by helpers, not a real issue I guess)
11:17:10 <BoekaBart> I didn't say only :)
11:17:12 <TrueBrain> and a lot of rewrite btw, the JIT makes mistake (see the JIT corruption earlier today)
11:17:23 <TrueBrain> so there is a lot more to it ;)
11:17:39 <TrueBrain> I also want to prepare it for other instructions sets (while at it)
11:19:41 <TrueBrain> and I don;t like the layout of how nodes are stored currently :p Ghehe :)
11:24:14 <TrueBrain> Xaroth: btw, about rescaling, it is very hard to increase pixel size 1.2 times or something of the like :)
11:25:56 <Xaroth> but maybe SDL had some tricks
11:27:20 <TrueBrain> dunno .. don't care at this point :p
11:32:24 <TrueBrain> BoekaBart: btw, this version of ToC took me about 3 months of work .. so don't expect a new version any time soon :p
11:32:36 <TrueBrain> doesn't mean you cant work on LibEMU :p It needs a SDL layer :p
12:01:57 <BoekaBart> SDL doesn't have scaling logic as far as I've been able to find
12:02:47 <BoekaBart> TrueBrain: you didn't commit the 'window' interface yet, right?
12:25:54 <TrueBrain> havent written it :p
13:08:29 <TrueBrain> I took the os/strings.h approach :)
13:08:34 <TrueBrain> can you please make it MSVC and mingw compatible? :) :)
13:15:08 <TrueBrain> I think 'f__01F7_28DC_0009_EE56' is strncmp ..
13:38:39 <TrueBrain> hmm .. I don't think undeffing the __STRICT_ANSI__ from that point on is the way to go
13:41:08 <glx> 'f__01F7_10C3_0010_64C2' is tolower
13:41:30 <glx> or the other way around (it does -0x20 if needed)
13:41:49 <TrueBrain> so indeed strncasecmp
13:43:10 <glx> ,...emu_testb(&emu_get_memory8(emu_ds, emu_bx, 0x76BD), 0x8); <-- so 0x76BD is a 256 bytes array ;)
13:44:52 <glx> and I think these flags are also used for isalnum, isalpha, ...
13:46:21 <glx> f__01F7_1097_0010_64C2 tolower
13:46:43 <TrueBrain> my scenario rewrite fails to work correctly :( That always makes me sad
13:47:10 <DorpsGek> SVN: truebrain (r462) -Add: soon we will need strncasecmp too, so document is already
13:47:29 <TrueBrain> glx: maybe for mingw set a temp flag, which recovers __STRICT_ANSI__ afterwards?
13:47:36 <TrueBrain> or prototype it ourself?
13:52:08 <TrueBrain> I don't get why my buildings don't show up ... everything checks out fine :(
13:55:32 <TrueBrain> auch ... uint8 can't hold values > 255 :p
13:57:44 <Xaroth> then you complement two of em? :)
13:58:08 <TrueBrain> I am not sure if the splitting of ',' is done nicely
13:58:40 <TrueBrain> for sure I am less forgiving than Dune2 is
13:58:56 <TrueBrain> as normally this was valud: Ordos,Const Yard,256
13:59:02 <TrueBrain> it would place it as position 256 with health 256
13:59:06 <TrueBrain> very useless of course
14:05:45 <DorpsGek> SVN: truebrain (r463) -Add: rewrote emu_Scenario_Load_Structures to be less emu_ like
14:06:23 <TrueBrain> glx: I think that is better? I don't reall yknow how to do it differently ..
14:06:40 <TrueBrain> except implementing strcasecmp ourself for mingw ;) (as that of course is the most safe thing, but very silly :p)
14:07:13 <TrueBrain> btw, is that * placement inconsistancy a typo from you, or is that really in the header?
14:08:23 <TrueBrain> LOL! Very nasty ....
14:08:36 <glx> well I removed an extra space for strncmp
14:08:43 <TrueBrain> hmm .. found 3 bugs in the scenario code already .. I hope this does not reflect the rest of the game :)
14:08:58 <TrueBrain> either way, glx, I can't think up a better way for now, so this will do just fine :)
14:09:25 <TrueBrain> and for now, I wish you all a very good day :)
14:09:31 <TrueBrain> off to dancing classes :)
14:10:26 <DorpsGek> SVN: glx (r464) -Fix (r461): make os/strings.h MSVC and MinGW compatible
14:10:40 <BoekaBart> "Fuzzy return at depth 2. Expected 0215:11DF, but got 0215:1357 from 0215:130D"
14:10:53 <BoekaBart> Anything I need to do about that?
14:12:20 <TrueBrain> it is one of those things that make decompiling hard
14:13:19 <BoekaBart> crash.bin isn't normally loaded ever, right?
14:13:26 <TrueBrain> I loaded it a lot :)
14:13:33 <TrueBrain> but currently the JIT is too damaged to give a correct result
14:13:41 <TrueBrain> a design flaw, we shall call it :)
14:13:45 <TrueBrain> either way, fuzzy results:
14:13:52 <TrueBrain> normally if you jump from point A to point Z
14:14:02 <TrueBrain> you expect to return at A+<instruction size of jump at A)
14:14:16 <TrueBrain> at point Z there should be a return, which takes care of that
14:14:23 <TrueBrain> but ... some applications do dirty tricks
14:14:33 <TrueBrain> to figure out cs:ip (you can't access 'ip' normally), and other shit
14:14:54 <TrueBrain> in this case, for some reason, a return doesn't return to A+<size>, but to D, totally not related to A or Z
14:15:03 <TrueBrain> so the decompiled code will fail
14:15:11 <TrueBrain> you have to manually investigate and correct it in the decompiled code
14:15:16 <TrueBrain> this is in Dune2 the src/patched.c
14:15:20 <TrueBrain> (Dune2 has one such instance)
14:15:56 <TrueBrain> in your case too .. the return should have gone to 11DF, but ended up at 1357, for the return at 130D
14:16:08 <TrueBrain> this is one of the nasty nasty things in 16bit world
14:16:12 <TrueBrain> k, really off now, running late :)\
14:29:00 <glx> hmm sprintf is deprecated :)
14:29:55 <glx> a pragma is enough to disable the warning :)
14:32:39 <BoekaBart> TrueBrain: so basically the 'use' a buffer overflow or smth to overwrite the return-IP on the stack or so?
14:37:29 <Xaroth> glx: not secure as in?
14:56:24 <Xaroth> btw glx, so you're aware as well, on the frontpage there's a separate category, 'developer blog' where you can post bits and odds regarding useful information you found
14:56:41 <Xaroth> tb will mostly be using it i think, but seeing you're actively developing as well :)
15:17:42 <BoekaBart> TrueBrain: bug report in libemu (old one): int10.11 falls through to int10.12 :(
16:04:44 *** BoekaBart has left #openDune
16:53:32 <Xaroth> glx: Memset_Internal to have value and count reversed to Memset?
16:53:52 <glx> yes, but it's usual in dune2 :)
16:54:52 <glx> check emu_String_Format, it's used internally by all *printf functions
17:18:27 <DorpsGek> SVN: glx (r465) -Add: figured out a few variables
19:58:08 *** BoekaBart has joined #openDune
19:58:15 <BoekaBart> did he stop dancing?
20:44:14 <TrueBrain> BoekaBart: and now, you can access the return ip very simple, as it is the first entry on the stack
20:45:18 <DorpsGek> SVN: truebrain (r466) [LibEMU] -Fix: INT10:11 missed a 'return' (boekabart)
20:46:52 <DorpsGek> SVN: truebrain (r467) -Add: figured out a few function names (glx)
20:48:46 <TrueBrain> coul;dn't resist a silly post :)
21:01:39 <TrueBrain> I guess BoekaBart left already .. his loss :p
21:05:20 <glx> Avertissement,...1,...warning C4244: '=' : conversion de 'uint16' en 'uint8', perte possible de données,...d:\developpement\opendune\src\scenario.c,...1076
21:05:20 <glx> Avertissement,...2,...warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.,...d:\developpement\opendune\src\scenario.c,...1093
21:05:38 <glx> I can "fix" the second with a pragma
21:06:29 <TrueBrain> fucking retarded MSVC with his stupid warnings
21:06:36 <TrueBrain> in this case it is absolutely wrong and it can never ever give any problem
21:06:45 <TrueBrain> (%c%03d is a very predefined size)
21:07:11 <glx> sprintf always warn with MSVC
21:07:33 <TrueBrain> that is just stupid
21:07:57 <TrueBrain> there are levels of insecure
21:08:09 <TrueBrain> k, snprintf is not a normal include in MSVC I assume?
21:08:39 <TrueBrain> it is a C99 function, even on Linux
21:09:50 <DorpsGek> SVN: truebrain (r468) -Fix: fix a silly MSVC warning
21:10:03 <TrueBrain> I dunno about the sprintf
21:10:13 <TrueBrain> solving is not possible in a simple way (as snprintf is not defined in C89)
21:10:24 <TrueBrain> and it is not wrong, not in any way .. but muting the warning is also not the best action
21:11:22 <TrueBrain> sprintf_s on MSVC, not?
21:11:30 <TrueBrain> but okay, doesn't matter, as Linux has problems with it
21:11:35 <TrueBrain> and I don't see an easy way to define snprintf
21:11:43 <TrueBrain> (except enabling C99 :p)
21:11:55 <TrueBrain> or _USE_BSD :p Ghehe :)
21:12:27 <glx> I can just disable the warning :)
21:12:51 <TrueBrain> it disables ALL such warnings, not?
21:12:56 <TrueBrain> which might not always be the best action
21:13:11 <glx> strdup is deprecated too btw
21:13:42 <TrueBrain> haha, that is always a good reason, yes :)
21:13:52 <TrueBrain> how on earth can you make a strdup that is bugged?
21:14:56 <TrueBrain> the _strdup is the ANSI/ISO version, strdup is not
21:15:04 <TrueBrain> GO MICROSOFT! GO! You never stop to amaze me ..
21:15:56 <TrueBrain> strdup is easy solved by redefining
21:16:04 <TrueBrain> so glx, I suggest that for now we leave this warning like it is
21:16:39 <TrueBrain> in the future we will have to look at snprintf (as will need it sooner or later), and then we can make MSVCrappy happy)
21:17:07 <glx> something for os/strings.h :)
21:17:40 <TrueBrain> I also love Microsoft for this: sprintf_s .. the 's' stands for 'secure'
21:17:51 <TrueBrain> where any other sane person just calls it snprintf, as that is what is 'secure' about it :p
21:18:17 <TrueBrain> but okay, we know that some snprintf implementations also don't add a \0 when they reach the max value
21:18:31 <TrueBrain> so fair enough, there also are crappy snprintf implementation on non-windows :p
21:18:56 <TrueBrain> ah, strdup is no C89
21:20:22 <TrueBrain> Microsoft deprecated all functions in C projects which are not C89 (ignoring C99, although for strdup it doesn't count, as it isnt in C99)
21:20:41 <TrueBrain> where GCC just gives a nice warning: this function is not ANSI C, which any sane compiler would have done :)
21:23:11 <glx> and don't forget the fun with wide chars ;)
21:23:24 <TrueBrain> I don;t even want to think about it ....
21:24:02 <TrueBrain> I completely understand there is no one true way to follow for any application and/or software, and varierity is a good thing ... just there are limits :p
21:26:52 <glx> char class functions use a smart implementation :)
21:28:04 <glx> and indeed checking a flag in memory is faster than using if
21:28:33 <TrueBrain> yeah, dune2 has many speed improvements :)
21:30:03 <glx> ,...if ((emu_get_memory8(emu_ds, emu_bx, 0x76BD) & 0x1) != 0) goto l__0604; <-- if ispace(emu_bx) goto
21:31:06 <glx> .,.../* 76BD(256) */ PACK uint8 character_class[256]; /*!< Flags: 0x01 - isspace, 0x02 - isdigit, 0x04 - isupper, 0x08 - islower, 0x10 - isxdigit && !isdigit, 0x20 - iscntrl, 0x40 - ispunct. */
21:31:07 <TrueBrain> stupid phone is out of service AGAIN :(
21:32:30 <TrueBrain> very clever method :)
21:33:59 <glx> so when it tests 0xE it's isalnum :)
21:35:25 <TrueBrain> sorry .. you have the flag first, then the explanation
21:35:32 <TrueBrain> misread it just 5 times in the last 4 minutes :) Ghehe :)
21:35:50 <glx> I used the same format as you :)
21:35:57 <TrueBrain> yeah, mine sucks :p
21:36:11 <TrueBrain> we should start making enums for such shit
21:36:16 <TrueBrain> but I am waaaayyyyyy too lazy :p
21:38:21 <TrueBrain> "By doing nothing time passes for sure"
21:40:52 <TrueBrain> glx: I believe that is the first time I ever saw you write only 2 characters on one line :)
21:41:11 <TrueBrain> (not in any negative way btw :))
21:43:29 <glx> f__01F7_03B2_0017_7CBE looks like a nice math function :)
21:44:00 <TrueBrain> test(ax, ax) .. wtf?
21:44:20 <TrueBrain> yes .. normally they use 'or' for that
21:45:42 <glx> probably si = ax; ax = dx
21:46:18 <TrueBrain> (all instant of course)
21:47:20 <TrueBrain> ax:bx and cx:dx appear to be 2 32bit values
21:47:55 <TrueBrain> euh: cx:bx and dx:ax of course
21:48:12 <TrueBrain> but it is also used with 16bit input values
21:52:47 <TrueBrain> it really is a complex function :)
21:53:57 <TrueBrain> I don't get the 'dx' value .. ax becomes si, dx becomes si, dx gets added a value (either ax or cx I believe) .. but .. si is never set before calling that function
21:55:41 <glx> with cx = 0 and dx = 0 it's just ax*bx
21:58:06 <glx> hmm I think it's just a 32bit mul
21:58:16 <TrueBrain> yes, but I can't decypher it :(
21:58:48 <glx> for now I traced 2 calls in debugger (both with dx=cx=0)
21:59:00 <TrueBrain> oh, wait .. didn't mul also set 'dx' ..
21:59:20 <TrueBrain> grr, I knew there couldn't come any good of my notation of mul :(
21:59:28 <TrueBrain> okay, that changes a lot
22:01:18 <glx> +,...,...emu_ax_i,...{s={...} x=0x0130 },...emu_reg_t
22:01:18 <glx> +,...,...emu_bx_i,...{s={...} x=0x6d39 },...emu_reg_t
22:01:18 <glx> +,...,...emu_cx_i,...{s={...} x=0x0000 },...emu_reg_t
22:01:18 <glx> +,...,...emu_dx_i,...{s={...} x=0x0000 },...emu_reg_t
22:01:33 <glx> this call will give more info I guess :)
22:01:49 <glx> as it will probably overflow in dx
22:02:30 <glx> previous were ax=70 or 78, bx=140
22:05:53 <TrueBrain> dx = (ax * bx) >> 16 + cx * ax + dx * bx
22:05:56 <TrueBrain> if I made no weird mistakes
22:06:16 <TrueBrain> so yes, 32bit mul :)
22:07:23 <TrueBrain> yeah, my above is correct, so your guess is spot on :)
22:07:56 <TrueBrain> f__01F7_03C9_001C_11C7 <- strdup
22:09:13 <glx> silly to mix args on stack and args in registers ;)
22:09:22 <TrueBrain> nowedays it is completely normal
22:09:27 <TrueBrain> but it is a bit odd in this case
22:09:49 <glx> yes it makes sense with optimisation
22:10:02 <TrueBrain> that is the reason gcc .o files don't understand MSVC .o files
22:10:09 <TrueBrain> because they use stack and registers differently for parameters
22:10:27 <glx> but gcc can use msvc .lib
22:10:37 <TrueBrain> because gcc cares about compatibility :)
22:10:47 <TrueBrain> and a .lib only contains information I believe
22:12:18 <TrueBrain> euh .. is f__01F7_079C_0017_78BE not identical to the function we just had?
22:13:58 <glx> not exactly, 03C9 uses CS:IP
22:14:26 <TrueBrain> means the latter is only used inside 01F7
22:14:33 <glx> so same function, but one is local call
22:15:18 <TrueBrain> f__01F7_07B3_0021_4ED6 compares 2 cs:ip pairs if they match
22:15:30 <TrueBrain> in the flat address space
22:16:30 <TrueBrain> f__01F7_1139_000D_AAB0 <- strlen, but didn't we already had one?
22:17:08 <TrueBrain> this is in a slightly different variant
22:21:47 <glx> but it does the "same" as strlen
22:22:56 <TrueBrain> not that strlen is such an inteligent function :p
22:23:35 <TrueBrain> k, I better get to bed now, I have a long day ahead of me tomorrow
22:24:24 <glx> hmm I miss info in some named function :)
22:24:32 <glx> let's create some crash.bin
22:35:05 <glx> looks like emu_String_strlen starts by checking the string pointer is not NULL
continue to next day ⏵