Trunk Revision 52678

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Trunk Revision 52678

Post by PurpleGurl »

Okay, I tried this from Live CD like the others. I first had to disable legacy mode in BIOS because the PS/2 mouse wouldn't work with it enabled despite that working in Windows. That was expected since I saw no new keyboard or mouse work in trunk, and no USB work. Then I checked to see what drives showed up in My Computer, and like before most of the drive letters are missing. I don't remember if any of the drives that did show were duplicated like before or not. At any rate, I went to the only FAT32 drive that was showing (out of 6, 9 volumes total since 3 are NTFS, and 2 of those display in Reactos).

Then I went to the Emulator Games folder and to GENS 2.11. (I know there is a newer version, but I know we cannot run it, since it relies on .NET, while this version doesn't. I don't use the newer GENS emulator since, despite a pause bug, 2.11 seems to work smoother and with less overhead.) Unlike last time, it loaded. There were no memory bugs at that point. I figured that would be how it was, since the LDR rewrite seemed responsible and it has had more work. However, also expected, was the left keyboard arrow problem in the Sega Traysia game as played through GENS. I could move up, down, and right using the arrows, but not left. I cannot remember if this was an issue the last time it worked, but the character seemed to run away. So I think we need to do some more arrow-related tests in Reactos and Windows using the test utility.

There were other problems with the game emulator, with at least one known to be a previous issue. That is full screen mode not hiding the taskbar. The taskbar intruded into the full screen mode of the emulator. That is an old bug (though probably not in Bugzilla, but we can check). Now, there is a more serious issue. It might be an old one too, but I don't remember. What happened was that after I messed around in the GENS emulator's options and command bar for a while, Reactos hung completely. There was no way to get a task manager nor restart dialog, nor even toggle the keyboard lights.

One good thing to say about playing the game in the emulator under Reactos is that it seemed more responsive than in Windows. I don't know if that is so much a Reactos thing, or just using the default video drivers. I guess that sometimes, for basic operations, standard VESA support drivers might actually be more efficient. It could also be the lack of an audio driver and the emulator not needing to devote time to emulating the 4 sound-related chips found in the Sega Genesis.

While I cannot play games under GENS 2.11 in Reactos, it does seem that the regressions from the LDR code may be handled. But the system hang from messing in the command bar, the task bar in full screen issue, and the left keyboard arrow issue are still there as before.
Last edited by PurpleGurl on Sun Jul 17, 2011 2:58 am, edited 1 time in total.
gabrielilardi
Moderator Team
Posts: 873
Joined: Sat Sep 02, 2006 1:30 am
Location: Italy

Re: Trunk Revision 52678

Post by gabrielilardi »

I first had to disable legacy mode in BIOS because the PS/2 mouse wouldn't work with it enabled despite that working in Windows
As hto said in your other thread, someone should file a bug about this, attaching two debug logs, so that there is more info about this and perhaps a dev could take a look.
I went to the only FAT32 drive that was showing (out of 6, 9 volumes total since 3 are NTFS, and 2 of those display in Reactos).
Probably bug 2564
However, also expected, was the left keyboard arrow problem in the Sega Traysia game as played through GENS. I could move up, down, and right using the arrows, but not left.
This is bug 4405
There were other problems with the game emulator, with at least one known to be a previous issue. That is full screen mode not hiding the taskbar
This is bug 6202
What happened was that after I messed around in the GENS emulator's options and command bar for a while, Reactos hung completely.
This could be anything, a debug log is needed to know what happened. Before wasting time, log to file won't help here.
Smiley
Developer
Posts: 156
Joined: Fri Nov 10, 2006 3:36 pm

Re: Trunk Revision 52678

Post by Smiley »

PurpleGurl wrote: Now, there is a more serious issue. It might be an old one too, but I don't remember. What happened was that after I messed around in the GENS emulator's options and command bar for a while, Reactos hung completely. There was no way to get a task manager nor restart dialog, nor even toggle the keyboard lights.
This sounds like a serious problem indeed. Could you create a bug for it with a way to reproduce?
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

Before wasting time, log to file won't help here.
It can if it's just a failed assert.
gabrielilardi
Moderator Team
Posts: 873
Joined: Sat Sep 02, 2006 1:30 am
Location: Italy

Post by gabrielilardi »

hto wrote:It can if it's just a failed assert.
Yeah, haven't thought about that, it's one possibility...
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Trunk Revision 52678

Post by PurpleGurl »

gabrielilardi wrote:
I first had to disable legacy mode in BIOS because the PS/2 mouse wouldn't work with it enabled despite that working in Windows
As hto said in your other thread, someone should file a bug about this, attaching two debug logs, so that there is more info about this and perhaps a dev could take a look.
I am not sure how to do this, I will have to reread what hto said. It looks like I need to take some initiative. Like said in yet another thread, if everyone decides to leave things for someone else, nothing will get done.
I went to the only FAT32 drive that was showing (out of 6, 9 volumes total since 3 are NTFS, and 2 of those display in Reactos).
Probably bug 2564
Not sure, since most of my drives are not visible in Reactos, even ones which should work in Reactos, but all display in XP. The first pattern I noticed so far was the cluster sizes. The ones that show are 4k, 16k, or 512 bytes. The ones that don't show are 2k, 8k, and 32k. However, I changed the cluster size of a volume and it is still not accessible in Reactos. So we can probably rule that out as a factor. But I spotted another pattern. It is not nothing that really can be tested other than seeing if others notice the same thing. The only partitions visible of the 9 are the first, 5th (middle), and last. I wonder if others with over 3 volumes on a drive are getting only their first middle, and last. I can only get into the middle and now last because they are FAT32 (expected, no NTFS support yet), but drives in position 1, 5, and 9 show up. And yes, there is still duplication of drive icons into different letters as suspected but not noticed earlier.
However, also expected, was the left keyboard arrow problem in the Sega Traysia game as played through GENS. I could move up, down, and right using the arrows, but not left.
This is bug 4405
Yes, indeed. That fits it accurately. The keys stick and the left arrow does not work.
There were other problems with the game emulator, with at least one known to be a previous issue. That is full screen mode not hiding the taskbar
This is bug 6202
Possibly. They provided no evidence in that bug that the icon hiding is related to incomplete full screen mode in programs. That is two different scenarios. On the desktop, really, that area of the screen should be considered non-writable. So if the icon drawing doesn't realize there is a taskbar and uses the wrong value to compute its clearance, then collisions are likely. In full screen mode, the task bar needs to find out that full screen mode for the top application is desired and to turn itself off until that program ends, changes modes, or is allowed to be pushed to the background. On the desktop, such icon overwriting seems to be the correct taskbar behavior, since the desktop drawing code should be expected to yield. But in an application, the taskbar is what is expected to yield. So it is just as possible that this is 2 issues rather than just one (desktop drawing and the taskbar not obeying full screen wishes).
What happened was that after I messed around in the GENS emulator's options and command bar for a while, Reactos hung completely.
This could be anything, a debug log is needed to know what happened. Before wasting time, log to file won't help here.
So what is the best approach for logging both the mouse/keyboard initialization issues and GENS causing Reactos to hang? Would a dual PC approach be the best? I guess with the game hang, I could try it in a virtual machine first.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

The ones that don't show are 2k, 8k, and 32k.
ReactOS works with these cluster sizes.
It is not nothing that really can be tested other than seeing if others notice the same thing.
Can you please save your FAT32 boot sectors and the MBR into files and upload somewhere (or attach them to a bug report in Bugzilla)?
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re:

Post by PurpleGurl »

hto wrote:
The ones that don't show are 2k, 8k, and 32k.
ReactOS works with these cluster sizes.
It is not nothing that really can be tested other than seeing if others notice the same thing.
Can you please save your FAT32 boot sectors and the MBR into files and upload somewhere (or attach them to a bug report in Bugzilla)?
I figured out by playing with the cluster sizes that this is not the issue. But, another pattern I noticed was that only the first (NTFS), middle (FAT32), and last (now FAT 32 since I converted it this morning). Those 3 show up and I can access the middle and last one. None of the rest show up, show their volume labels, nor are accessible.

Plus, all the drives show up twice. I do wonder if running a RAID 1 set is part of the issue.

The comment about not being able to test applied more to the position of the working drives (first drive, middle drive, last drive). The cluster size concern was easily tested and dismissed as a theory.

Now what do I use to retrieve the boot sectors and MBR? Any utilities you recommend?
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

Try DD from here.

Paste the output of "dd --list" here. Also, do "dd count=1 if=\\?\Device\Harddisk0\Partition0 of=hd0-mbr" and upload that "hd0-mbr" file. If you have more then one hard disk attached, then repeat it for other HarddiskN devices.
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re:

Post by PurpleGurl »

hto wrote:Try DD from here.

Paste the output of "dd --list" here. Also, do "dd count=1 if=\\?\Device\Harddisk0\Partition0 of=hd0-mbr" and upload that "hd0-mbr" file. If you have more then one hard disk attached, then repeat it for other HarddiskN devices.
How do I paste the output of the first usage? It won't let me pipe "dd --list" to a filename. It refuses to go anywhere but to stdout. It doesn't matter if I use DOS style pipe operators, or if I use the of= argument. The 2nd part works well.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

It does not go to stdout, but to stderr. If you want to redirect it to the file , use the following syntax:

command 2> file

Or highlight the text in the console window with mouse, then copy it to the clipboard.
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re:

Post by PurpleGurl »

hto wrote:It does not go to stdout, but to stderr. If you want to redirect it to the file , use the following syntax:

command 2> file

Or highlight the text in the console window with mouse, then copy it to the clipboard.
I thought it was way too much data to C&P from the clipboard until I found I could change the CMD screen buffer. So I copied and pasted using a virtual screen 6 times the size of the default screen. After I did it that way, I realized you included a "2" in the above (I always used DOS pipes without the 2) and I tried it just to see, and it worked. I didn't need the log at that point since I already increased the virtual screen to 150 lines and C&P the text from there.

Code: Select all

G:\Wintemp\File Utils\MBR\dd>dd --list
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.

Win32 Available Volume Information
\\.\Volume{92286e86-16c9-11dd-8a26-806d6172696f}\
  link to \\?\Device\HarddiskVolume1
  fixed media
  Mounted on \\.\l:

\\.\Volume{5b929f26-4231-11e0-94f5-001d601dc8da}\
  link to \\?\Device\HarddiskVolume2
  fixed media
  Mounted on \\.\k:

\\.\Volume{5b929f29-4231-11e0-94f5-001d601dc8da}\
  link to \\?\Device\HarddiskVolume3
  fixed media
  Mounted on \\.\i:

\\.\Volume{5b929f2d-4231-11e0-94f5-001d601dc8da}\
  link to \\?\Device\HarddiskVolume4
  fixed media
  Mounted on \\.\h:

\\.\Volume{5b929f32-4231-11e0-94f5-001d601dc8da}\
  link to \\?\Device\HarddiskVolume5
  fixed media
  Mounted on \\.\g:

\\.\Volume{5b929f36-4231-11e0-94f5-001d601dc8da}\
  link to \\?\Device\HarddiskVolume6
  fixed media
  Mounted on \\.\f:

\\.\Volume{35e95cda-4258-11e0-a1af-806d6172696f}\
  link to \\?\Device\HarddiskVolume7
  fixed media
  Mounted on \\.\e:

\\.\Volume{0b0a1182-425b-11e0-a1b3-001d601dc8da}\
  link to \\?\Device\HarddiskVolume8
  fixed media
  Mounted on \\.\d:

\\.\Volume{92286e8e-16c9-11dd-8a26-806d6172696f}\
  link to \\?\Device\HarddiskVolume9
  fixed media
  Mounted on \\.\c:

\\.\Volume{c13d3dc4-db29-11df-94c9-806d6172696f}\
  link to \\?\Device\CdRom0
  CD-ROM
  Mounted on \\.\m:

\\.\Volume{07d97c34-5d0e-11de-89ae-001d601dc8da}\
  link to \\?\Device\Floppy0
  removeable media
  Mounted on \\.\a:

\\.\Volume{335be730-41c4-11de-a93e-001d601dc8da}\
  link to \\?\Device\CdRom1
  CD-ROM
  Mounted on \\.\w:

\\.\Volume{335be731-41c4-11de-a93e-001d601dc8da}\
  link to \\?\Device\Harddisk1\DP(1)0-0+b
  removeable media
  Mounted on \\.\x:


NT Block Device Objects
\\?\Device\CdRom0
  Removable media other than floppy. Block size = 2048
  size is 136136704 bytes
\\?\Device\CdRom1
  size is 10487808 bytes
\\?\Device\Floppy0
  3.5,  1.44MB, 512 bytes/sector. Block size = 512
  size is 1474560 bytes
\\?\Device\Harddisk0\Partition0
  link to \\?\Device\Harddisk0\DR0
  Fixed hard disk media. Block size = 512
  size is 320072908800 bytes
\\?\Device\Harddisk0\Partition1
  link to \\?\Device\HarddiskVolume9
\\?\Device\Harddisk0\Partition2
  link to \\?\Device\HarddiskVolume8
\\?\Device\Harddisk0\Partition3
  link to \\?\Device\HarddiskVolume7
\\?\Device\Harddisk0\Partition4
  link to \\?\Device\HarddiskVolume6
  Fixed hard disk media. Block size = 512
  size is 77317599744 bytes
\\?\Device\Harddisk0\Partition5
  link to \\?\Device\HarddiskVolume5
\\?\Device\Harddisk0\Partition6
  link to \\?\Device\HarddiskVolume4
  Fixed hard disk media. Block size = 512
  size is 80081293824 bytes
\\?\Device\Harddisk0\Partition7
  link to \\?\Device\HarddiskVolume3
  Fixed hard disk media. Block size = 512
  size is 11712766464 bytes
\\?\Device\Harddisk0\Partition8
  link to \\?\Device\HarddiskVolume2
  Fixed hard disk media. Block size = 512
  size is 80994299904 bytes
\\?\Device\Harddisk0\Partition9
  link to \\?\Device\HarddiskVolume1
  Fixed hard disk media. Block size = 512
  size is 1381814784 bytes
\\?\Device\Harddisk1\Partition0
  link to \\?\Device\Harddisk1\DR10
\\?\Device\Harddisk1\Partition1
  link to \\?\Device\Harddisk1\DP(1)0-0+b

Virtual input devices
 /dev/zero   (null data)
 /dev/random (pseudo-random data)
 -           (standard input)

Virtual output devices
 -           (standard output)
 /dev/null   (discard the data)
----
Is that of any help? Or do you still want the raw dumps from each partition? And where do you want me to put them since they are in binary? I am having complications making all the MBR files. I took the template you gave and pasted into a batch file and modified it for all assumed iterations. Apparently, DD refused to make some of the files. I will need to verify the NT-style partition addresses. But from what I see, you will probably want to see the files. There are 3-4 different jump addresses in the MBR code, different boot failure messages, and 1 partition with seemingly no valid machine code in the MBR other than the first 3 bytes, but with what I know of the table entries in the correct places. It looks like a number of variations. I am studying them to see any structural patterns in what is working or not working.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

Which of those partitions are accessible in ReactOS? Many of them must be logical, rather then primary. So it can be because of bug 2564, as already mentioned by gabrielilardi.

The MBR of the 1st hard disk is on \\?\Device\Harddisk0\Partition0.

Use any file hosting or Bugzilla to upload.
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re:

Post by PurpleGurl »

hto wrote:Which of those partitions are accessible in ReactOS? Many of them must be logical, rather then primary. So it can be because of bug 2564, as already mentioned by gabrielilardi.

The MBR of the 1st hard disk is on \\?\Device\Harddisk0\Partition0.

Use any file hosting or Bugzilla to upload.
Drives C, G, and L were the only ones Reactos would even recognize. G was the only one that would open originally since it was the only FAT32 of the 3 Reactos could find.

As for the partitions, only the first is a primary partition, and that is C - "C-Drive" and I have its MBR already. Since it is in use, it one of the ones I am unable to copy the VBR for its logical partition (because XP wants sole access). It is NTFS, but it shows up in Reactos as a drive letter and with its volume name.

Logical partition D - "Temp Drive" is one I set up for XP temp files for easy maintenance. It is also NTFS. Reactos doesn't see it, and again, Windows has it locked.

Logical partition E - "SWAP DRIVE" is one I set up just for the swap file. It is also locked by Windows (and trying a forced unlock gets a BSOD) and unavailable for a MBR dump too, unless I make one obvious adjustment and move the swap file using the control panel). It is FAT32, but doesn't not show up in Reactos.

Logical drive F - "Videos" is FAT32 and not visible in Reactos. It is FAT32 and I have a DD dump of it.

Logical drive G - "FILE BIN" is FAT32, and before I converted L to FAT32, the only one Reactos could open. I was at first unable to create a dump of it, but I moved the utility to another drive and closed everything related to G and used Unlocker to verify all handles to it were closed. Then DD worked fine. That one has some stub code in the MBR where if you try to boot to it, it says it is not a system drive.

Logical Drive H - "Music" is FAT32, and not recognized by Reactos.

Logical Drive I - "H-DRIVE" (I know inconsistent volume label, but I reordered the partitions and needed a reminded of where it moved to) is FAT32 and not recognized by Reactos. That is the one where I said it appeared in the dump that there was no code in it, just the parameters and all.

Logical Drive K - "C......." is FAT32 and not recognized in Reactos.

Logical Drive L - "G....." is now FAT32 and apparently readable in Reactos. I hated converting it since that caused the folders to fragment and XP is unable to defragment FAT32 folders (buggy API that defraggers know not to touch and why I proposed an API without the bug so either 9X style defraggers could be tricked to work without harm, or we could get one developer, even 3rd party, to write one that will do that job in Reactos).
----

So why does G and L work if Reactos cannot read logical units? If we knew that, then we might be able to patch Reactos or at least modify the partitions some.
Last edited by PurpleGurl on Sun Jul 17, 2011 8:14 pm, edited 1 time in total.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

So why does G and L work if Reactos cannot read logical units?
It's hard to say without looking at the boot records.

They all are available through \\?\Device\Harddisk0\Partition0, using dd skip=N.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 33 guests