profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/stsp/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

dosemu2/dosemu2 278

Run DOS programs under linux:

dosemu2/fdpp 82

FreeDOS plus-plus, 64bit DOS

dosemu2/comcom32 16

32bit command.com

dosemu2/win31-mouse-driver 12

Universal (int 33h) mouse driver for Windows 3.1

stsp/sst2k 8

Super Star Trek 2K

einmalfel/git-aflow 3

Git-aflow is git-flow alternative, it provides some more flexibility over git-flow

stsp/pmdapi 2

protected mode DOS API translator

stsp/BeholdT8 1

BeholdTV T8 driver

stsp/clang-libdos 1

A "sub standard" C library for real-mode dos applications

stsp/fdkernel 1

FreeDOS kernel - implements the core MS-DOS/PC-DOS (R) compatible operating system. It is derived from Pat Villani's DOS-C kernel and released under the GPL v2. Please see http://www.freedos.org/ for more details about the FreeDOS (TM) Project.

release dosemu2/fdpp

1.4

released time in 3 days

created tagdosemu2/fdpp

tag1.4

FreeDOS plus-plus, 64bit DOS

created time in 3 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

Does freedos really need to be compiled to exe, or is it that ia16-gcc can't compile to elf format? Hmm... I vaguely recall that they needed some elf extensions to be able to avoid exe format, and IIRC such extensions were added to ia16-gcc (but not yet to nasm). So why do they still use exe, is unclear for me. They could start from switching to elf, and eventually becoming fdpp. :)

andrewbird

comment created time in 3 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

Note that inte6 was only used by dosemu-provided tools. It never presented some external APIs because dosemu2 is not a development platform and should mostly never provide any external APIs. All extensions currently go to fdpp. Note that even fdpp uses the bootsector-provided entry point rather than inte6 to stay dosemu-agnostic.

So the use of inte6 outside of dosemu-supplied tools, is not at all obvious. And freedos is not the random prog out there - its something that should run from bare metal. It may be more consistent to provide the extensions to it via a boot sector, or may not. Adding just some debugging API to inte6 doesn't sound like a big deal to me from dosemu2's side. But how good is that for freedos, is up to someone else to decide.

andrewbird

comment created time in 3 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

If it was initially set to NULL, you crash. If it was set to iret - np.

andrewbird

comment created time in 3 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

E6 can be considered indeed, but in that case you will need to check if you are under dosemu or not. The alternative can be to pass the call address in boot sector where there are currently zeros. Then you would only check for zeros.

andrewbird

comment created time in 3 days

issue openeddosemu2/fdpp

run directly from HMA?

In principle we can load fdpp directly to HMA. This will mean that all freedos-alike relocations should be disabled, and the Dyn heap must be put after INIT_TEXT to not overwrite code. This will mean that INIT_TEXT won't be discarded, but at the same time there will be no need for INIT_TEXT at all. All relocation machinery can then be removed. That would be a huge departure from the freedos architecture, with lots of simplifications and code removals. Whether it worth the trouble, is unclear as of yet.

created time in 3 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

Also its not really hard to add reloc hook to freedos. The places where it should be added, can be looked up in fdpp. Note that even though the relocation code in fdpp was rewritten, it does essentially the same thing as before, and fdpp relocates itself 2 times, similar to freedos. So you can get a very good hint about adding the reloc hook to freedos. Even though fdpp is now relocated to UMB by an elf loader, the freedos-alike runtime relocations are all still there.

andrewbird

comment created time in 3 days

issue commentdosemu2/dosemu2

write lock manager for share modes and protection of opened files

I applied the data flush patch for safety anyway. It shouldn't hurt.

stsp

comment created time in 3 days

push eventdosemu2/dosemu2

Stas Sergeev

commit sha 90cb90c6c2b71948eb5ba21086c9eb9538edd918

mfs: flush file before releasing locks [#1345]

view details

push time in 3 days

issue commentdosemu2/dosemu2

write lock manager for share modes and protection of opened files

Are you using share/deny modes or file locks?

stsp

comment created time in 3 days

issue commentdosemu2/dosemu2

write lock manager for share modes and protection of opened files

So its not a dosemu problem then?

stsp

comment created time in 3 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

I would still suggest to fix the freedos ld script to match the (IMO correct) expectations of your current code. This will bring you closer to using the map with bpload.

andrewbird

comment created time in 3 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

I had assumed it would be correct after fully booting.

This can be easily proven wrong by the fact that after boot, freedos runs in HMA.

andrewbird

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

I think that there's no load addresses in the FDPP .MAP file because you never use section .data AT address

Yes but that only means there is no need for more than 1 load address, and the first (and only) one is zero. On freedos you want to use the second (non-zero) load address, but that's a bug. And if they by mistake put 2 or 3 sections in the beginning w/o marking them as NOLOAD, you will need to skip even more load_addresses, and take, eg 4th one. See?

I had assumed it would be correct after fully booting.

No and in fact, I recalled that freedos immediately jumps to the moved/copied INIT_TEXT. So the only thing you can do, is to add the reloc hook, the same way fdpp does.

andrewbird

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

NOTE2: freedos has some unmovable bits, so at least your mapfile will show the same things it currently shows with fdpp. But freedos has much, much more realmode symbols than fdpp has, and they all will disappear after Move.

andrewbird

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

at 0079, rather than the 0000 that FreeDOS has so the values need nothing other than adding the origin of 0x0060.

Yes, that's the point. Move operation is irrelevant. So we are on the same page now. :) And what remains, seems to be just the missing NOLOAD.

NOTE: freedos has the same Move operation. So your map file will only work during early boot.

andrewbird

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

I think if you add the (proper!) NOLOAD, nothing will remain. Segment will be calculated as origin+load_address, so what else is to desire?

andrewbird

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

I know! I said we don't use load address, and there are none in the .MAP file from FDPP.

I think this is a very confusing statement. There is no load address in an fdpp map file not because it doesn't use something, but because the first load address is always 0, and is probably therefore just not printed in the map file. In freedos you've found non-first (and non-zero therefore) load address and say "freedos uses load address", but I think you are just taking the second load address, and there is still the first one, too, which is equal to 0. So it would be a kludge if you take the second load address (one of many, why not the last one or third one then?) and subtract it from CS. THAT is the kludge. I think the bug is simple: they forgot to mark their first section as NOLOAD. If they did, there would be no things like "they use load address and fdpp not". So IMHO you are trying to propagate their bug too widely.

andrewbird

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

Seems like a kludge to me. Gcc compiled kernel 0x55(CS-0xb) and Watcom compiled kernel 0x60(CS)

Mm, actually, is this even a good thing to have? I suppose they later do some objcopy-alike business to remove the first 0xb0 bytes (is this what exeflat tool does?). Can you instead change their ld script to have load address from 0 and the first section to be NOLOAD? Not sure if it is good to work around on our side, what do you think?

andrewbird

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

I know! I said we don't use load address, and there are none in the .MAP file from FDPP.

OK, I see. I was confused by this: FDPP doesn't use the load address, as you move the symbols because to me these 2 seems unrelated to each other. We don't use load address when calculating the origin for the call of mhp_usermap_load_gnuld(map, SREG(cs)); not when we move it, which is optional.

Seems like a kludge to me. Gcc compiled kernel 0x55(CS-0xb) and Watcom compiled kernel 0x60(CS)

OK so your idea seems to be to only pass CS and have the function to do the calculus itself? That would be fine with me. I just don't think As the load address parsing looks to be remaining for FreeDOS, because there may be other uses, like external exe file.

andrewbird

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

No, we still do mhp_usermap_load_gnuld(map, SREG(cs)); for fdpp. Yes, its later moved, but that's not the point. You can debug it before it got moved, for example. The point is that we DO specify the origin. And its CS for fdpp and CS-0xb for freedos.

I think in the future it would be nice if usermap load-* could handle .EXEs that use multiple segments, though I've no idea at the moment how.

I don't think its too difficult, because all those "multiple segments" are layed out consequently, just like in freedos case. So I think the single origin is still enough. But I can of course miss something obvious here.

andrewbird

comment created time in 4 days

issue commentdosemu2/dosemu2

write lock manager for share modes and protection of opened files

Will something like this help?

diff --git a/src/dosext/mfs/mfs.c b/src/dosext/mfs/mfs.c
index 624984733..9282041ef 100644
--- a/src/dosext/mfs/mfs.c
+++ b/src/dosext/mfs/mfs.c
@@ -3421,6 +3421,9 @@ static int lock_file_region(int fd, int lck, long long start,
 {
   struct flock fl;
 
+  if (!lck)
+    dos_flush(fd);
+
 #ifdef F_GETLK64       // 64bit locks are promoted automatically (e.g. glibc)
   static_assert(sizeof(struct flock) == sizeof(struct flock64), "incompatible flock64");
 
stsp

comment created time in 4 days

issue commentdosemu2/dosemu2

write lock manager for share modes and protection of opened files

They probably don't respect each other's locks

I hope they only do not respect each other's "share modes". I believe (or at least hope so) the locks should work quite well.

smb client side cachingandopportunistic locking

I think this is only relevant for SMB clients, like cifsfs, but it probably does not expose that "feature" to the posix FS that it provides. Because there is probably no such thing in posix, so I would guess that cifsfs just disables that feature on its own.

stsp

comment created time in 4 days

issue commentdosemu2/dosemu2

write lock manager for share modes and protection of opened files

It is probably missing in dosemu2. Andrew can check that. :)

stsp

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

Could you please provide an example of what do you mean? I think we only have some "pre-defined" set of use-cases for this mapload. We need it for bios.s, for fdpp, for freedos, and - for what else? Maybe you can make it play well with bpload, so that it can load the map file relative to the start segment, which is known at the bpload time? Not sure what use cases you have in the mind.

andrewbird

comment created time in 4 days

issue commentdosemu2/dosemu2

write lock manager for share modes and protection of opened files

Let's start from simplest theories. Maybe we forget fsync() (aka dos_flush() ) when locks are released?

stsp

comment created time in 4 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

So for fdpp we do: mhp_usermap_load_gnuld(map, SREG(cs)); For freedos, I suppose fatfs.c should then do: mhp_usermap_load_gnuld(map, SREG(cs) - 0xb); Does this make sense?

andrewbird

comment created time in 6 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

I'll try, but perhaps I need to somehow distinguish between programs that need an origin for the address that DOS loads them at and Freedos kernel where perhaps the addresses should be resolved from zero,

So it should be 0x55 and not zero.

andrewbird

comment created time in 6 days

pull request commentdosemu2/dosemu2

Dosdebug: Remove load_address from Gnu LD map parser

OK, all you need to do is to add 0x55 to load address. 0x0000000000000550 MEMOFS = ((DOS_PSP * 0x10) - SIZEOF (.msdos_mz_hdr))

So 0x840 becomes 0xd9: 0x84+0x55=0xd9. As you can see, PSP loads at b0:

.ptext          0x0000000000000000      0x100 load address 0x00000000000000b0
 *(PSP)

And at the same time PSP loads to 0x60:0. So the actual image with MZ header is loaded to 0x55:0.

andrewbird

comment created time in 6 days