- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [sir_richard] 48825: [MISC]: Fix several compiler issues on my main build box. Some of the Unicode translations in kernel32 fail to compile, while other libraries don't build because old C library ...
by Timo Kreuzer 28 Sep '10

28 Sep '10

sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Mon Sep 20 06:30:21 2010 > New Revision: 48825 > > > +  > + <define name="lseek">_lseek</define> > + <define name="read">_read</define> > + <define name="strdup">_strdup</define> > What's not "proper" with our oldnames library?

4 3

HTTP/WebDAV access for the Git mirror
by Colin Finck 26 Sep '10

26 Sep '10

Hello everybody, Just to let you know, I've just added HTTP/WebDAV access for our read-only Git mirror as requested by a developer. This means that you can also clone from http://git.reactos.org/reactos.git now if you sit behind a firewall blocking the Git protocol. Of course, the previous URL git://git.reactos.org/reactos.git will continue to work. Best regards, Colin

2 2

platform dependent configuration files
by Matthias Kupfer 26 Sep '10

26 Sep '10

HI, recently I had to alter some inf-files for fixing a bug. At present we have for each platform (i386, arm, amd64) separate files, which are hard to maintain because of some identical, that aren't platform dependent. Therefore I suggest the following change and I will write an example and the necessary tool: - combine all platforms to one file and work with special block markers - block markers work like filters, empty markers means all platforms otherwise the platforms limited to are given in comma separated lists - we have to maintain only one single file and the alteration is minimal, because the marker is a simple (syntactically comment) line like ";#platform_a,platform_b#" or ";##" - the needed file is extracted at build time, always up-to-date and shipped in the same way as present General remark: we have to make some efforts to bring (or at least to keep) the project in understandable and maintanable state. We have to use and introduce tools to reduce needless efforts resulted by managing multiple similar files which could be better generated without failures (that people tends to do). This and only this is my intention for this suggestion. Request for comments - other ways or changes with same goal are welcome Matthias -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany

2 1

OpenSource World Conference-Malaga(Spain)
by victor martinez 24 Sep '10

24 Sep '10

Hi guys/devs/testers/translators/followers ! I have just received this information from the OSWC organization: "Nos complace comunicarle que su propuesta presentada al Call for Paper ha sido aprobada de forma preliminar por el Comité de Ponencias de la Conferencia Internacional de Software Libre para su comunicación pública. Actualmente el programa de la Conferencia se encuentra en una fase temprana de elaboración, por ello solicitamos de usted nos comunique antes del próximo día 28 de septiembre de 2010, su disponibilidad para estar en Málaga tanto el día 27 de octubre, el 28 o ambos. Agradecemos su dedicación e interés y esperamos disfrutar de su compañía en Málaga Atentamente " You can use Google translator. Or summing up: "We are IN" Thanks to anyone who has voted and wish me good luck :) If anyone is interested about coming, please contact me before 28 September (there is one day just for professionals and closed to the general public) :) Victor Martinez "

2 2

Re: [ros-dev] 0.3.12 milestones status
by victor martinez 23 Sep '10

23 Sep '10

> From: gedmurphy(a)gmail.com > To: ros-dev(a)reactos.org > Date: Thu, 23 Sep 2010 08:09:57 +0100 > Subject: Re: [ros-dev] 0.3.12 milestones status > > victor Martinez wrote: > > > In the same way, and imho, I think it is much better > > to avoid sending critical code one month before the release. > > This isn't how you release. > The whole point in branching for a release is so you can stabalise the > branch whilst trunk continues to be 'bleeding edge' > What's the point in branching otherwise? We may as well just tag trunk and > do away with branching. I am not agree :) As far as i see we have tried to (more or less)stabilize trunk before branching at least in the 2 latest releases. An i.e is the 0.3.12 release, if we are following the "bleeding edge" concept then we should have branched several months ago and just pulled the regression fixes from trunk to the branch. Our approach was different: Stabilizing trunk fixing the known regressions (which,btw,were marked as Milestones) and then branching. There is not an incompatibility with the "stabilizing trunk" and "branching" concepts. First because exists the "Hack-releases" (fixes just applied for the release) and that just can be done in a branch. Second because a (more or less) stabilized trunk doesn't mean a regression-free trunk (but it could be). The first main advantage (about avoid sending critical code in the month we are going to release) is that we will have a whole month to check if the critical changes has waken up underlying bugs (or if the critical changes has introduced Eisenbugs).If we are following the "bleeding edge" approach we can just pray to find those Eisenbugs in the Release Candidate ISO tests and, since there aren't a lot of testers checking the RC ISO, it is quite unprovable. The second main advantage is that we reduce the Release Engineers amount of work. It is not the same bugging them to create just one RC ISO than bugging them to create 2 or 3 because playing with the "bleeding edge" concept.

4 4

Re: [ros-dev] 0.3.12 milestones status
by victor martinez 23 Sep '10

23 Sep '10

> > I am not agree :) As far as i see we have tried to (more or less) > > stabilize trunk before branching at least in the 2 latest releases. > This is because trunk has been in a mess for the past few releases. > Due to its instability it wasn't worth branching it as it was so far from > being releasable. > In the past we had (strived for) a 2 month release cycle. > We branched every 2 months no matter what and then worked on getting that > release out. > This is how linux and most other serious open source projects work. It's all > about discipline. "About discipline" and about having a lot of developers which can cover all the needs a project has. ;) And let me not talk about some "serious open source pojects" with tons developers/users which has introduced and released with critical regressions. > > There is not an incompatibility with the "stabilizing trunk" and > > "branching" concepts. First because exists the "Hack-releases" (fixes > > just applied for the release) and that just can be done in a branch. > > Second because a (more or less) stabilized trunk doesn't mean a > > regression-free trunk (but it could be). > This is exactly what it's for. Branch, fix bugs or hack bugs away. > Merge real bug fixes back into trunk, tag and release. Sure, I was just answering to your "What's the point in branching otherwise?" which seemed to be a question about an incompatibility with "avoiding critical commits" and "stabilizing trunk" before branching. > > The first main advantage (about avoid sending critical code in the > > month we are going to release) is that we will have a whole month to check > > if the critical changes has waken up underlying bugs > > This is the ongoing job of the testers to do both in trunk and more > importantly, in release branch. > If any serious bugs are found late in the process, drop the branch, fix in > trunk and rebranch. Just 2 words: Im-possible. :) You need a testing time frame. There is something called "Probability" of finding a regression(even more finding an eisenbug). If you branch right after a critical commit and that critical commit has introduced a regression you have much less "Probability" to find it that if the last critical commit was made 1 month ago. Even more, Release Candidates are mainly just tested by the Testers. So finding the regression depends mainly on "Probability Testers find a regression in one week" But during that Quarantine month other commits (non critical ones) can be sent and developers can feel/find regressions too. So finding the regressions would depend mainly on "Probability Testers and Devs find a regression in one month". Notice that the testing group is wider and so the time. We don't have Testing manpower to find a regression the next day/week it was commited. > > The second main advantage is that we reduce the Release Engineers amount of work. > But you hamper development. Locking down trunk for a month before every > release is a sure way to drive away all of your developers. > I would refuse to work on a project which worked in this way, as would most > other devs I assume. Who talked about freezing trunk? I should define 1-month Quarantine better: "Avoid commiting to critical areas. The trunk is open for those non-critical ones. You can send meanwhile your critical patches to a branch and after the release pushing them to trunk.". You have a ReactOS branch if needed. > If you're finding when release time comes that no devs work on fixing the > release branch and instead continue adding new code to trunk, then you have > a developer discipline issue not a release process issue. If we pay our developers we can ask for discipline meanwhile we can just accept their patches or refuse them. Will you refuse a Patch? Or maybe revoke a Dev commit access to create discipline? Any useful ideas? > Locking trunk is just a way to work around your developer discipline problem > instead of tackling the real problem, your devs can't be bothered to fix > existing code and continue to ignore their duties and add new code instead. Noone talked about Locking Trunk, and there are no duties. IIRC you were the first person that explained me why there are no dutie$ in this project. > Ged. Vic

2 1

Trunk freeze
by Aleksey Bragin 23 Sep '10

23 Sep '10

Hello, 0.3.12 was branched today, so I removed the lock from trunk. However, I want to really ask everyone not to jump into modern fancy features but pay more attention to fixing core parts of the system. Victor is doing the change log draft, and if Colin has time I would like to ask him to apply our usual release stuff. WBR, Aleksey Bragin.

1 0

0.3.12 Changelog Sum up.
by victor martinez 23 Sep '10

23 Sep '10

You have done a pretty cool work. 0.3.12 Changelog is opened, I have added a "Regression", "General Bugs" section where i reflect the Bugs fixed from 0.3.11 to 0.3.12. This is a little bit more user-friendly. You can find it here: http://www.reactos.org/wiki/ChangeLog-0.3.12#General The Bugzilla stats shows the next: - There were 259 General Bugs fixed (Regressions fixed are not counted here) - There were 20 Translations sent in 11 different Languages. - And you fixed 61 Regressions So more than 320 bugs has been fixed in less than 300 days. (Without counting Bugfixes in branch) You have killed more than 10 bugs older than 3 years old. And the eldest one is "#969 Minimized windows are shown on desktop" which is 5 years old. Congratz :)

1 0

Debug Build is Broken
by James Tabor 22 Sep '10

22 Sep '10

[CC] dll/win32/kernel32/file/file.c cc1: warnings being treated as errors dll/win32/kernel32/file/dir.c:21: error: 'gDebugChannel' defined but not used make: *** [/mnt/ramdisk/buildbot/release/obj/dll/win32/kernel32/file/dir_kernel32.o] Error 1 make: *** Waiting for unfinished jobs....

2 2

Unable to use FreeLDR
by Ros Arm 21 Sep '10

21 Sep '10

Hello, After the switch in 48124 to PE FreeLDR, I am unable to boot FreeLDR any longer. I have tried official, as well as various unofficial freeldr.sys, none worked. 47892 version works fine, 48124 does not. On a 512MB IDE disk, I got the "_" VGA cursor scrolling endlessly/randomly on the screen, before even seeing "Loading FreeLDR..." With a 1GB SCSI disk, tested also with a 6GB IDE disk, it remains stuck at "Loading FreeLDR...". This seems strange: "Now booting from fat partitions (looks like that's what sysreg does) works again. It's safe under the condition that the cluster size is at least 4352 bytes, which is true for harddisks of sizes bigger than 272MB. Booting from smaller fat disks, like floppy breaks when freeldr.sys gets fragmented, which should rarely happen." Please advise. -r

3 7

Re: [ros-dev] [ros-diffs] [sir_richard] 48825: [MISC]: Fix several compiler issues on my main build box. Some of the Unicode translations in kernel32 fail to compile, while other libraries don't build because old C library ...
by Aleksey Bragin 20 Sep '10

20 Sep '10

On Sep 20, 2010, at 10:30 AM, sir_richard(a)svn.reactos.org wrote: > Author: sir_richard > Date: Mon Sep 20 06:30:21 2010 > New Revision: 48825 > + <define name="lseek">_lseek</define> > + <define name="read">_read</define> Please use TABs in .rbuild files for indentation. Thanks, Aleksey Bragin.

1 0

pefixup doesnot set IMAGE_SCN_MEM_NOT_PAGED for .rdata WDM section
by Pavel Pisa 18 Sep '10

18 Sep '10

Hello all, I have noticed, that pxefixup does not set IMAGE_SCN_MEM_NOT_PAGED flag for read-only data section ".rdata". May it be, that it is problem for my own build of tools 586-mingw32-gcc (GCC) 4.4.2 and GNU ld (GNU Binutils) 2.20.51.20100608 I have fixed the problem by preparing modified LD script version which collect object files .rdata section into .text section for my driver build. But .rdata is legitimate section and it is automatically generated by GCC. I have not found information in Wiki or list archives, that there is some way/patch to deal with this situation. But if it is allowed, that WDM driver binaries contains readonly section then data paging could lead to horrible consequences. Possible fix diff --git a/reactos/tools/pefixup.c b/reactos/tools/pefixup.c index f908a9a..d6ec1f4 100644 --- a/reactos/tools/pefixup.c +++ b/reactos/tools/pefixup.c @@ -381,6 +381,7 @@ int main(int argc, char **argv) if (!strcmp((char*)section_header->Name, ".text") || !strcmp((char*)section_header->Name, ".data") || !strcmp((char*)section_header->Name, ".idata") || + !strcmp((char*)section_header->Name, ".rdata") || !strcmp((char*)section_header->Name, ".bss")) { section_header->Characteristics |= htodl(IMAGE_SCN_MEM_NOT_PAGED); If .rdata are not allowed or should be used only for pseudo_reloc, then the ldscript for kernel code should be provided. Missing flag for .rdata section in objdump ouput $ i586-mingw32-objdump --headers ul_wdm.sys BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .text BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .data BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .bss BFD: ul_wdm.sys: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .idata ul_wdm.sys: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0000cabc 00011000 00011000 00001000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 000000e8 0001e000 0001e000 0000e000 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .rdata 00003c20 0001f000 0001f000 0000f000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .bss 00000050 00023000 00023000 00000000 2**2 ALLOC 4 .edata 00000033 00024000 00024000 00013000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .idata 000008c4 00025000 00025000 00014000 2**2 CONTENTS, ALLOC, LOAD, DATA 6 .rsrc 0000035c 00026000 00026000 00015000 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .reloc 00000cd4 00027000 00027000 00016000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rossym 0001576d 00028000 00028000 00017000 2**2 CONTENTS, READONLY, NEVER_LOAD, EXCLUDE

2 2

reactos in lguest
by Enrico Weigelt 17 Sep '10

17 Sep '10

Hi folks, did anyone already do some research on whether ReactOS could run in lguest ? Maybe this could be a nice for development/debugging and attracting more people ;-) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

5 6

0.3.12 TODO list
by Olaf Siejka 17 Sep '10

17 Sep '10

As we progress into regression fixing, we are now in the good moment to decide upon upcoming release. It would be great if we could manage with the 0.3.12 for the October Chemnitz event, where we are invited again to participate, not to mention that its the time for such release. Right now, in my opinion we should decide without futher delay on the following: - reviewing the REGRESSION list, this is - to confirm entries with 0.3.12 milestone already set, as well as doublecheck the rest, to see if any should be promoted to said milestone. This is the action of most utter importance, as there is no way to know how much time will be spent on futher research, testing and fixing them; - decide upon bugs originated with last ole/comctl sync - are we haxing them locally, risking another winesync or perhaps reverting? - reviewing patches stored at http://www.reactos.org/wiki/Bug_Filters as well as deciding if any should be adapted for current release. Those actions, first of them especially, should be performed as swift as possible, else we might risk considerable delay and nervous finish before the Chemnitz.

5 6

ASSERT while shutting down ReactOS with VirtualBox Guest Additions installed
by Javier Agustìn Fernàndez Arroyo 17 Sep '10

17 Sep '10

hello, this is to sir_richard, mostly, i got this crash (assert) when shutting down ReactOS with the VirtualBox Guest Additions installed. i think the video driver is guilty for some reason i cannot understand... probably you know :) http://www.reactos.org/paste/index.php/7731/

6 13

uLan USB driver for ReactOS - query for help if possible
by Pavel Pisa 16 Sep '10

16 Sep '10

Hello to all ReactOS developers, thanks for great work. I introduce our case first. -------------------------------------------------------------------- We have developed, maintain and use uLan RS-485 multi-master protocol for years - sources traced to 1992 year. The protocol is used by multiple companies and individuals for broad range of applications from laboratory instruments control, home automation to agriculture feeding and milking systems. We started by Linux support. But due to customers demand, we have added Windows KDM and later WDM support as well. I remember, that pointer to our driver has been mentioned as one of little fully open-source drivers available for Windows on ReactOS list many many years ago. The uLan project homepage http://ulan.sourceforge.net/ The uLan driver code can be compiled for Linux, Windows NT KDM, Win98/2k/Vista WDM, plain DOS, system-less ARM and other devices. The old legacy UART, PCI addon cards and USB converters are supported for Linux and WDM version. All builds form same sources with unification layer of macros which unifies systems to something more close to Linux driver model. The code is not so elegant and readable, the portability layers are quite complex and sometimes hairy tasks. The traces of old age of project can be seen there as well. But it works and may it be, it could be some example and source of helpers functions for porting of Linux USB drivers to WDM model. The ReactOS has got to the stage where it is able to run one of our user applications utilizing our control protocol link. Because I believe in open technologies, I would be very happy if the project is usable even on RectOS - even that I do not expect that our users could and want to switch anytime soon or ever. The Open Chromatography Station - CHROMuLAN http://sourceforge.net/projects/chromulan/ If you think that it worth, it can be added to the list of applications working with ReactOS 0.4-git/svn. -------------------------------------------------------------------- As for the uLan driver. I have maneged it build for WDF with PCI and UART support only to run on ReactOS and whole CHROMuLAN setup seems to be functional. I have even interrest to build driver code with ReactOS to test it more, find incompatibilities and continue with 64-bit testing in future. The effort seems to be not so far form success. The driver builds with RectOS build under Linux when USB support is disabled. The build with USB seems to be near as well. There are two main problems: 1) We need to include usbdlib.h in the driver build, but DECLSPEC_EXPORT in this header is not declared/maintained. We use this file for next types declaration USBD_INTERFACE_LIST_ENTRY PUSBD_INTERFACE_LIST_ENTRY struct _USBD_INTERFACE_LIST_ENTRY' May it be, we should use different include headers, but next setup works for years with Microsoft WDF #include "wdm.h" #include "usbdi.h" #include "usbdlib.h" 2) If we overcome by some hack problem 1) the link fails on undefined references to __imp__USBD_ParseConfigurationDescriptorEx@28 __imp__USBD_CreateConfigurationRequestEx@8 There seems to be traces of implementation of these functions in ReactOS old/disabled USB code. The functions are even included in usbd.sys, usbd.exp and drivers/usb/usbd . But import library seems to be missing. Am I right? Is there way to use them or plan to solve that. Thanks for reply in advance. Even that we do not much expect to use ReactOS build in production environment the option has value for us. It allows to test Windows builds in Linux environment without need to start Wine for WDF. ReactOS build even helped us to find some real bugs in our code because rectos runtime is more strict in some checks then Windows systems. Please, keep my email addres in reply, I do not expect (have ability) to follow ReactOS development closely between my other duties. It is unfortunate a little, that only way to contact developers on the list is to subscribe. Best wishes, Pavel -- Pavel Pisa e-mail: pisa(a)cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/

4 4

From what to start?
by Captain Sandro 15 Sep '10

15 Sep '10

What can you advice me to start from? Which module needed in programming? And which tools and methods are used for writing code?

3 2

Errata
by Olaf Siejka 14 Sep '10

14 Sep '10

Altough i mentioned Chemitz, it should be of course OpenSource World Conference in Spain. Sorry

1 0

Windows & ReactOS installed simultaneously
by Javier Agustìn Fernàndez Arroyo 14 Sep '10

14 Sep '10

Hello devs, Few users at spanish ReactOS blog ( http://reactos.wordpress.com ) are asking about having both Windows and ReactOS installed in different partitions at the same time... And i wanted you to answer, rather than me... :P What would you say? Is it currently possible?

7 10

A room for improvement?
by Pierre Schweitzer 13 Sep '10

13 Sep '10

Hi, while working on GPT handling for ReactOS, one thing appeared: Microsoft (at least in Windows 2003 SP1) is using hardcoded partition entry size, ie it assumes that every partition entry in GPT will be 128 bytes big. Even if that assertion is largely right, it might exist cases where it's wrong. That's even why there's a field in GPT header that contains such size. Furthermore, reading Apple technical note(1) about GPT precise one more thing: "Do not hardwire the current size of the partition entry (128 bytes).". As we have no commercial issues with Apple, perhaps could we drop a bit compatibility with Windows 2003 and fix something obvious? In most cases, users won't see any difference. Only difference would be that ReactOS could properly handle GPT with exotic partition entry size when Windows can't. Any opinion on that subject? Best regards, P. Schweitzer (1): http://developer.apple.com/library/mac/#technotes/tn2006/tn2166.html

2 2

48748 "Goodbye" Confusion
by Ros Arm 12 Sep '10

12 Sep '10

Hello, eVb checked in one of his final patches yesterday from his development machine in China, where we worked on a final pass on the driver. Unfortunately, my last two (unrelated) check ins were done from his machine (as most of you know, I was in China for the past month), and he was not used to SVN caching the credentials of the last user. Revision 48748 was a checkin from eVb, and his "goodbye" was in reference to my departure. Since it used my cached credentials from the same machine, it must've caused a lot of confusion. Many apologies and thanks for understanding. -r

1 0

Re: [ros-dev] [ros-diffs] [fireball] 48745: [NTOS] - Daniel Zimmermann: Fix POPF bugs in VDM mode, namely truncation of the stackpointer to 16 bit and setting proper flags in the trapframe eflags register. This fixes proble...
by Timo Kreuzer 12 Sep '10

12 Sep '10

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Sat Sep 11 09:20:26 2010 > New Revision: 48745 > ... > /* Save EFlags */ > + Esp -= 4; > + *(PULONG)(Esp - 2) = V86EFlags; > This looks wrong to me. The (Esp - 2) I mean. > + if (KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32) > + { > + /* Read EFlags */ > + EFlags = *(PULONG)Esp; > + Esp += 4; > + } > + else > + { > + /* Read EFlags */ > + EFlags = *(PUSHORT)Esp; > + Esp += 2; > /* Read correct flags and use correct stack address */ > - Esp -= 2; > EFlags &= 0xFFFF; > Here the comment got broken a bit. > /* Set new ESP */ > - TrapFrame->HardwareEsp = Esp; > + TrapFrame->HardwareEsp = (USHORT)Esp; > This is not correct. We earlier calculated the flat Esp from Ss and Sp. Example: HardwareSegSs = 0x10, HardwareEsp = 0x10 -> flat Esp = 0x110, then you substract 4, and get 0x10C. But this is not the value of the new HardwareEsp. TrapFrame->HardwareEsp needs to be either modified in parallel to the flat Esp or calculated like (USHORT)(Esp - (TrapFrame->HardwareSegSs << 4)). Regards, Timo

1 0

Pacth: Freeldr disk geometry bug
by Eric Kohl 09 Sep '10

09 Sep '10

Hi! This patch fixes the disk geometry bug I mentioned in my previous mail. It enables disk.sys and usetup.exe to use the same disk geometry that is used by the BIOS. Due to another bug or workaround in the 1st stage setup, the 2nd stage setup will not boot at all. Regards, Eric Index: boot/freeldr/freeldr/arch/i386/hardware.c =================================================================== --- boot/freeldr/freeldr/arch/i386/hardware.c (revision 48722) +++ boot/freeldr/freeldr/arch/i386/hardware.c (working copy) @@ -327,7 +327,6 @@ { PCM_PARTIAL_RESOURCE_LIST PartialResourceList; PCM_DISK_GEOMETRY_DEVICE_DATA DiskGeometry; - EXTENDED_GEOMETRY ExtGeometry; GEOMETRY Geometry; ULONG Size; @@ -362,16 +361,8 @@ DiskGeometry = (PVOID)(((ULONG_PTR)PartialResourceList) + sizeof(CM_PARTIAL_RESOURCE_LIST)); /* Get the disk geometry */ - ExtGeometry.Size = sizeof(EXTENDED_GEOMETRY); - if (DiskGetExtendedDriveParameters(DriveNumber, &ExtGeometry, ExtGeometry.Size)) + if(MachDiskGetDriveGeometry(DriveNumber, &Geometry)) { - DiskGeometry->BytesPerSector = ExtGeometry.BytesPerSector; - DiskGeometry->NumberOfCylinders = ExtGeometry.Cylinders; - DiskGeometry->SectorsPerTrack = ExtGeometry.SectorsPerTrack; - DiskGeometry->NumberOfHeads = ExtGeometry.Heads; - } - else if(MachDiskGetDriveGeometry(DriveNumber, &Geometry)) - { DiskGeometry->BytesPerSector = Geometry.BytesPerSector; DiskGeometry->NumberOfCylinders = Geometry.Cylinders; DiskGeometry->SectorsPerTrack = Geometry.Sectors; Index: boot/freeldr/freeldr/arch/i386/pcdisk.c =================================================================== --- boot/freeldr/freeldr/arch/i386/pcdisk.c (revision 48722) +++ boot/freeldr/freeldr/arch/i386/pcdisk.c (working copy) @@ -296,12 +296,25 @@ BOOLEAN PcDiskGetDriveGeometry(ULONG DriveNumber, PGEOMETRY Geometry) { + EXTENDED_GEOMETRY ExtGeometry; REGS RegsIn; REGS RegsOut; ULONG Cylinders; DPRINTM(DPRINT_DISK, "DiskGetDriveGeometry()\n"); + /* Try to get the extended geometry first */ + ExtGeometry.Size = sizeof(EXTENDED_GEOMETRY); + if (DiskGetExtendedDriveParameters(DriveNumber, &ExtGeometry, ExtGeometry.Size)) + { + Geometry->Cylinders = ExtGeometry.Cylinders; + Geometry->Heads = ExtGeometry.Heads; + Geometry->Sectors = ExtGeometry.SectorsPerTrack; + Geometry->BytesPerSector = ExtGeometry.BytesPerSector; + + return TRUE; + } + /* BIOS Int 13h, function 08h - Get drive parameters * AH = 08h * DL = drive (bit 7 set for hard disk)

5 8

Severe bug found: Freeldr passes wrong disk geometry to ntoskrnl.exe and disk.sys
by Eric Kohl 09 Sep '10

09 Sep '10

Hi! I just found a severe bug in hardware detection code of Freeldr. It uses two configuration nodes in the hardware tree to pass information about detected hard-disks to ntoskrnl.exe and disk.sys. First, hard-disk information is passed as a DiskPeripheral node attached to a DiskController node. Second, hard-disk information is passed as an array of CM_INT13_DRIVE_PARAMETER entries in a special system configuration node, if the disks were detected by the BIOS. As part of the boot process, the special system configuration node is used by disk.sys to determine the disk geometry used by the BIOS. Unfortunately, this configuration node did not use the extended disk geometry (LBA geometry) but the old CHS geometry even if the LBA geometry was available. I already fixed this bug in my local source tree and suddenly Freeldr, disk.sys and usetup.exe report exactly the same disk geometry as gparted (http://gparted.sourceforge.net/download.php). Unfortunately, using this patch breaks the 2nd stage setup. I will provide a patch that fixes the Freeldr issue as soon as I have cleaned up the source tree. Please help me find the remaining bug or workaround that keeps ReactOS from booting into 2nd stage setup! I guess it is either part of usetup or somewhere in the partition management routines. Regards, Eric

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 48687: [FREELDR] - Convert fat12/16 boot sector helper code to gas syntax. Brought to you by the Arty. [CMAKE] - Add freeldr and setupldr to build.
by Alex Ionescu 07 Sep '10

07 Sep '10

This is retarded, GAS supports Intel syntax. Why did this require rewriting everything in AT&T syntax and introducing bugs? And what's up with calling AT&T syntax "GAS" Syntax. I wonder what Brian would say.... It's funny how this project gets rid of old developers, gets new developers, and has them make the same mistakes/idiotic things the old developers left for in the first place... Good job! Best regards, Alex Ionescu On Thu, Sep 2, 2010 at 10:39 AM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Thu Sep 2 17:39:45 2010 > New Revision: 48687 > > URL: http://svn.reactos.org/svn/reactos?rev=48687&view=rev > Log: > [FREELDR] > - Convert fat12/16 boot sector helper code to gas syntax. Brought to you by the Arty. > [CMAKE] > - Add freeldr and setupldr to build. > > Added: > branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.S > - copied, changed from r48568, branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm > Removed: > branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm > Modified: > branches/cmake-bringup/boot/CMakeLists.txt > > Modified: branches/cmake-bringup/boot/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/boot/CMakeLists.t… > ============================================================================== > --- branches/cmake-bringup/boot/CMakeLists.txt [iso-8859-1] (original) > +++ branches/cmake-bringup/boot/CMakeLists.txt [iso-8859-1] Thu Sep 2 17:39:45 2010 > @@ -5,3 +5,203 @@ > CreateBootSectorTarget(fat ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/bootsect/fat.asm ${CMAKE_CURRENT_BINARY_DIR}/freeldr/bootsect/fat.bin) > CreateBootSectorTarget(isoboot ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/bootsect/isoboot.asm ${CMAKE_CURRENT_BINARY_DIR}/freeldr/bootsect/isoboot.bin) > CreateBootSectorTarget(isobtrt ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/bootsect/isobtrt.asm ${CMAKE_CURRENT_BINARY_DIR}/freeldr/bootsect/isobtrt.bin) > + > +include_directories(BEFORE freeldr/freeldr/include) > +include_directories(${REACTOS_SOURCE_DIR}/ntoskrnl/include) > + > +if(ARCH MATCHES i386) > +list(APPEND FREELDR_STARTUP_SOURCE > + freeldr/freeldr/arch/i386/fathelp.S > + freeldr/freeldr/arch/i386/arch.S) > +elseif(ARCH MATCHES amd64) > +list(APPEND FREELDR_STARTUP_SOURCE > + freeldr/freeldr/arch/amd64/fathelp.S > + freeldr/freeldr/arch/amd64/arch.S) > +endif(ARCH MATCHES i386) > + > +if(ARCH MATCHES i386) > +list(APPEND FREELDR_BASE64K_SOURCE > + freeldr/freeldr/arch/i386/boot.S > + freeldr/freeldr/arch/i386/drvmap.S > + freeldr/freeldr/arch/i386/i386cpu.S > + freeldr/freeldr/arch/i386/i386idt.S > + freeldr/freeldr/arch/i386/i386pnp.S > + freeldr/freeldr/arch/i386/i386trap.S > + freeldr/freeldr/arch/i386/int386.S > + freeldr/freeldr/arch/i386/linux.S > + freeldr/freeldr/arch/i386/mb.S) > +elseif(ARCH MATCHES amd64) > +list(APPEND FREELDR_BASE64K_SOURCE > + freeldr/freeldr/arch/amd64/drvmap.S > + freeldr/freeldr/arch/amd64/i386cpu.S > + freeldr/freeldr/arch/amd64/i386idt.S > + freeldr/freeldr/arch/amd64/i386trap.S > + freeldr/freeldr/arch/amd64/mb.S) > +endif(ARCH MATCHES i386) > + > +set_source_files_properties(${FREELDR_BASE64K_SOURCE} PROPERTIES COMPILE_DEFINITIONS "_NTHAL_") > + > +include_directories(${REACTOS_SOURCE_DIR}/lib/cmlib) > + > +list(APPEND FREELDR_BASE_SOURCE > + freeldr/freeldr/arcemul/mm.c > + freeldr/freeldr/arcemul/time.c > + freeldr/freeldr/cache/blocklist.c > + freeldr/freeldr/cache/cache.c > + freeldr/freeldr/comm/rs232.c > + freeldr/freeldr/disk/disk.c > + freeldr/freeldr/disk/partition.c > + freeldr/freeldr/disk/ramdisk.c > + freeldr/freeldr/fs/ext2.c > + freeldr/freeldr/fs/fat.c > + freeldr/freeldr/fs/fs.c > + freeldr/freeldr/fs/iso.c > + freeldr/freeldr/fs/ntfs.c > + freeldr/freeldr/inifile/ini_init.c > + freeldr/freeldr/inifile/inifile.c > + freeldr/freeldr/inifile/parse.c > + freeldr/freeldr/mm/meminit.c > + freeldr/freeldr/mm/mm.c > + freeldr/freeldr/reactos/registry.c > + freeldr/freeldr/reactos/arcname.c > + freeldr/freeldr/reactos/archwsup.c > + freeldr/freeldr/reactos/binhive.c > + freeldr/freeldr/reactos/reactos.c > + freeldr/freeldr/reactos/imageldr.c > + freeldr/freeldr/rtl/bget.c > + freeldr/freeldr/rtl/libsupp.c > + freeldr/freeldr/ui/directui.c > + freeldr/freeldr/ui/gui.c > + freeldr/freeldr/ui/minitui.c > + freeldr/freeldr/ui/noui.c > + freeldr/freeldr/ui/tui.c > + freeldr/freeldr/ui/tuimenu.c > + freeldr/freeldr/ui/ui.c > + freeldr/freeldr/video/fade.c > + freeldr/freeldr/video/palette.c > + freeldr/freeldr/video/video.c > + freeldr/freeldr/windows/conversion.c > + freeldr/freeldr/windows/peloader.c > + freeldr/freeldr/windows/winldr.c > + freeldr/freeldr/windows/wlmemory.c > + freeldr/freeldr/windows/wlregistry.c > + freeldr/freeldr/freeldr.c > + freeldr/freeldr/debug.c > + freeldr/freeldr/version.c > + freeldr/freeldr/cmdline.c > + freeldr/freeldr/machine.c > + freeldr/freeldr/options.c > + freeldr/freeldr/linuxboot.c > + freeldr/freeldr/oslist.c) > + > +if(ARCH MATCHES i386) > +list(APPEND FREELDR_BASE_SOURCE freeldr/freeldr/disk/scsiport.c) > +endif(ARCH MATCHES i386) > + > +set_source_files_properties(${FREELDR_BASE_SOURCE} PROPERTIES COMPILE_DEFINITIONS "_NTHAL_;_BLDR_;_NTSYSTEM_") > + > +include_directories(${REACTOS_SOURCE_DIR}/include/reactos/libs) > +include_directories(${REACTOS_SOURCE_DIR}/include/reactos/elf) > + > +if(ARCH MATCHES i386) > +list(APPEND FREELDR_ARCH_SOURCE > + freeldr/freeldr/arch/i386/_alloca.S > + freeldr/freeldr/arch/i386/archmach.c > + freeldr/freeldr/arch/i386/custom.c > + freeldr/freeldr/arch/i386/drivemap.c > + freeldr/freeldr/arch/i386/halstub.c > + freeldr/freeldr/arch/i386/hardware.c > + freeldr/freeldr/arch/i386/hwacpi.c > + freeldr/freeldr/arch/i386/hwapm.c > + freeldr/freeldr/arch/i386/hwpci.c > + freeldr/freeldr/arch/i386/i386disk.c > + freeldr/freeldr/arch/i386/i386rtl.c > + freeldr/freeldr/arch/i386/i386vid.c > + freeldr/freeldr/arch/i386/loader.c > + freeldr/freeldr/arch/i386/machpc.c > + freeldr/freeldr/arch/i386/miscboot.c > + freeldr/freeldr/arch/i386/ntoskrnl.c > + freeldr/freeldr/arch/i386/pccons.c > + freeldr/freeldr/arch/i386/pcdisk.c > + freeldr/freeldr/arch/i386/pcmem.c > + freeldr/freeldr/arch/i386/pcrtc.c > + freeldr/freeldr/arch/i386/pcvideo.c > + freeldr/freeldr/arch/i386/machxbox.c > + freeldr/freeldr/arch/i386/xboxcons.c > + freeldr/freeldr/arch/i386/xboxdisk.c > + freeldr/freeldr/arch/i386/xboxfont.c > + freeldr/freeldr/arch/i386/xboxhw.c > + freeldr/freeldr/arch/i386/xboxi2c.c > + freeldr/freeldr/arch/i386/xboxmem.c > + freeldr/freeldr/arch/i386/xboxrtc.c > + freeldr/freeldr/arch/i386/xboxvideo.c > + freeldr/freeldr/windows/i386/ntsetup.c > + freeldr/freeldr/windows/i386/wlmemory.c) > +else() > +#TBD > +endif(ARCH MATCHES i386) > + > +set_source_files_properties(${FREELDR_ARCH_SOURCE} PROPERTIES COMPILE_DEFINITIONS "_NTHAL_;_BLDR_;_NTSYSTEM_") > + > +list(APPEND SETUPLDR_MAIN_SOURCE > + freeldr/freeldr/bootmgr.c > + freeldr/freeldr/inffile/inffile.c > + freeldr/freeldr/reactos/setupldr.c) > + > +if(ARCH MATCHES i386) > +list(APPEND SETUPLDR_MAIN_SOURCE freeldr/freeldr/windows/setupldr2.c) > +elseif(ARCH MATCHES amd64) > +list(APPEND SETUPLDR_MAIN_SOURCE freeldr/freeldr/windows/setupldr2.c) > +endif(ARCH MATCHES i386) > + > +set_source_files_properties(${SETUPLDR_MAIN_SOURCE} PROPERTIES COMPILE_DEFINITIONS "_NTHAL_;FREELDR_REACTOS_SETUP" COMPILE_FLAGS "-ffreestanding -fno-builtin -fno-inline -fno-zero-initialized-in-bss") > + > +set(CMAKE_C_CREATE_SHARED_LIBRARY "<CMAKE_C_COMPILER> <CMAKE_SHARED_LIBRARY_C_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS> -o <TARGET> <OBJECTS> <LINK_LIBRARIES>") > + > +list(APPEND FREELDR_SOURCE > + freeldr/freeldr/bootmgr.c > + ${FREELDR_STARTUP_SOURCE} > + ${FREELDR_BASE64K_SOURCE} > + ${FREELDR_BASE_SOURCE} > + ${FREELDR_ARCH_SOURCE}) > + > +add_library(freeldr SHARED > + ${CMAKE_CURRENT_BINARY_DIR}/freeldr_freeldr.h.gch > + ${FREELDR_SOURCE}) > + > +set_target_properties(freeldr PROPERTIES LINK_FLAGS "-Wl,--strip-all -Wl,-entry,_mainCRTStartup -Wl,--image-base,0x8000 -Wl,--exclude-all-symbols -Wl,--subsystem,native" SUFFIX ".sys") > + > +if(ARCH MATCHES i386) > +target_link_libraries(freeldr mini_hal) > +endif(ARCH MATCHES i386) > + > +target_link_libraries(freeldr > + rossym > + cmlib > + rtl > + libcntpr) > +add_pch(freeldr ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/freeldr/include/freeldr.h ${FREELDR_SOURCE}) > + > +list(APPEND SETUPLDR_SOURCE > + ${FREELDR_STARTUP_SOURCE} > + ${FREELDR_BASE64K_SOURCE} > + ${FREELDR_BASE_SOURCE} > + ${FREELDR_ARCH_SOURCE} > + ${SETUPLDR_MAIN_SOURCE}) > + > +add_library(setupldr SHARED > + ${CMAKE_CURRENT_BINARY_DIR}/freeldr_freeldr.h.gch > + ${SETUPLDR_SOURCE}) > + > +set_target_properties(setupldr PROPERTIES LINK_FLAGS "-Wl,--strip-all -Wl,-entry,_mainCRTStartup -Wl,--image-base,0x8000 -Wl,--exclude-all-symbols -Wl,--subsystem,native" SUFFIX ".sys") > + > +if(ARCH MATCHES i386) > +target_link_libraries(setupldr mini_hal) > +endif(ARCH MATCHES i386) > + > +target_link_libraries(setupldr > + rossym > + cmlib > + rtl > + libcntpr) > +add_pch(setupldr ${CMAKE_CURRENT_SOURCE_DIR}/freeldr/freeldr/include/freeldr.h ${SETUPLDR_SOURCE}) > > Copied: branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.S (from r48568, branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm) > URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/boot/freeldr/free… > ============================================================================== > --- branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm [iso-8859-1] (original) > +++ branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.S [iso-8859-1] Thu Sep 2 17:39:45 2010 > @@ -1,226 +1,222 @@ > -; FATHELP.ASM > -; FAT12/16 Boot Sector Helper Code > -; Copyright (c) 1998, 2001, 2002, 2003 Brian Palmer > - > - > - > -;org 8000h > - > -segment .text > - > -bits 16 > - > - > -BootSectorStackTop equ 0x7bf2 > -DataAreaStartHigh equ 0x2 > -DataAreaStartLow equ 0x4 > -BiosCHSDriveSizeHigh equ 0x6 > -BiosCHSDriveSizeLow equ 0x8 > -BiosCHSDriveSize equ 0x8 > -ReadSectorsOffset equ 0xa > -ReadClusterOffset equ 0xc > -PutCharsOffset equ 0xe > - > -OEMName equ 3 > -BytesPerSector equ 11 > -SectsPerCluster equ 13 > -ReservedSectors equ 14 > -NumberOfFats equ 16 > -MaxRootEntries equ 17 > -TotalSectors equ 19 > -MediaDescriptor equ 21 > -SectorsPerFat equ 22 > -SectorsPerTrack equ 24 > -NumberOfHeads equ 26 > -HiddenSectors equ 28 > -TotalSectorsBig equ 32 > -BootDrive equ 36 > -Reserved equ 37 > -ExtendSig equ 38 > -SerialNumber equ 39 > -VolumeLabel equ 43 > -FileSystem equ 54 > - > -BootPartition equ 0x7dfd > +// FATHELP.ASM > +// FAT12/16 Boot Sector Helper Code > +// Copyright (c) 1998, 2001, 2002, 2003 Brian Palmer > + > + .text > + .code16 > + .intel_syntax > + > +#define BootSectorStackTop 0x7bf2 > +#define DataAreaStartHigh 0x2 > +#define DataAreaStartLow 0x4 > +#define BiosCHSDriveSizeHigh 0x6 > +#define BiosCHSDriveSizeLow 0x8 > +#define BiosCHSDriveSize 0x8 > +#define ReadSectorsOffset 0xa > +#define ReadClusterOffset 0xc > +#define PutCharsOffset 0xe > + > +#define OEMName 3 > +#define BytesPerSector 11 > +#define SectsPerCluster 13 > +#define ReservedSectors 14 > +#define NumberOfFats 16 > +#define MaxRootEntries 17 > +#define TotalSectors 19 > +#define MediaDescriptor 21 > +#define SectorsPerFat 22 > +#define SectorsPerTrack 24 > +#define NumberOfHeads 26 > +#define HiddenSectors 28 > +#define TotalSectorsBig 32 > +#define BootDrive 36 > +#define Reserved 37 > +#define ExtendSig 38 > +#define SerialNumber 39 > +#define VolumeLabel 43 > +#define FileSystem 54 > + > +#define BootPartition 0x7dfd > > > -; This code will be stored in the first 512 bytes > -; of freeldr.sys. The first 3 bytes will be a jmp > -; instruction to skip past the FAT helper code > -; that is stored in the rest of the 512 bytes. > -; > -; This code is loaded at 0000:8000 so we have to > -; encode a jmp instruction to jump to 0000:8200 > - > -global _mainCRTStartup ; For Mingw32 builds where the linker looks for this symbol > +// This code will be stored in the first 512 bytes > +// of freeldr.sys. The first 3 bytes will be a jmp > +// instruction to skip past the FAT helper code > +// that is stored in the rest of the 512 bytes. > +// > +// This code is loaded at 0000:8000 so we have to > +// encode a jmp instruction to jump to 0000:8200 > + > +.globl _mainCRTStartup /* For Mingw32 builds where the linker looks for this symbol */ > _mainCRTStartup: > -global start > +.globl start > start: > - db 0xe9 > - db 0xfd > - db 0x01 > - > -; Now starts the extra boot code that we will store > -; in the first 512 bytes of freeldr.sys. This code > -; allows the FAT12/16 bootsector to navigate the > -; FAT table so that we can still load freeldr.sys > -; even if it is fragmented. > + .byte 0xe9 > + .byte 0xfd > + .byte 0x01 > + > +// Now starts the extra boot code that we will store > +// in the first 512 bytes of freeldr.sys. This code > +// allows the FAT12/16 bootsector to navigate the > +// FAT table so that we can still load freeldr.sys > +// even if it is fragmented. > > > FatHelperEntryPoint: > > - push ax ; First save AX - the start cluster of freeldr.sys > - > - > - ; Display "Loading FreeLoader..." message > - mov esi,msgLoading ; Loading message > - call [bp-PutCharsOffset] ; Display it > + push %ax /* First save AX - the start cluster of freeldr.sys */ > + > + > + // Display "Loading FreeLoader..." message > + mov %esi,msgLoading /* Loading message */ > + call [%bp-PutCharsOffset] /* Display it */ > > > call ReadFatIntoMemory > > - pop ax ; Restore AX (start cluster) > - ; AX has start cluster of freeldr.sys > - > - mov bx,800h > - mov es,bx > + pop %ax /* Restore AX (start cluster) */ > + // AX has start cluster of freeldr.sys > + > + mov %bx,0x800 > + mov %es,%bx > > LoadFile: > - push ax > + push %ax > call IsFat12 > - pop ax > + pop %ax > jnc LoadFile2 > - cmp ax,0ff8h ; Check to see if this is the last cluster in the chain > + cmp %ax,0xff8 /* Check to see if this is the last cluster in the chain */ > jmp LoadFile3 > LoadFile2: > - cmp ax,0fff8h > + cmp %ax,0xfff8 > LoadFile3: > - jae LoadFile_Done ; If so continue, if not then read then next one > - push ax > - xor bx,bx ; Load ROSLDR starting at 0000:8000h > - push es > - call [bp-ReadClusterOffset] > - pop es > - > - xor bx,bx > - mov bl,BYTE [BYTE bp+SectsPerCluster] > - shl bx,5 ; BX = BX * 512 / 16 > - mov ax,es ; Increment the load address by > - add ax,bx ; The size of a cluster > - mov es,ax > + jae LoadFile_Done /* If so continue, if not then read then next one */ > + push %ax > + xor %bx,%bx /* Load ROSLDR starting at 0000:8000h */ > + push %es > + call [%bp-ReadClusterOffset] > + pop %es > + > + xor %bx,%bx > + mov %bl,BYTE [%bp+SectsPerCluster] > + shl %bx,5 /* BX = BX * 512 / 16 */ > + mov %ax,%es /* Increment the load address by */ > + add %ax,%bx /* The size of a cluster */ > + mov %es,%ax > > call IsFat12 > - pop ax > - push es > + pop %ax > + push %es > jnc LoadFile4 > - call GetFatEntry12 ; Get the next entry > + call GetFatEntry12 /* Get the next entry */ > jmp LoadFile5 > LoadFile4: > call GetFatEntry16 > LoadFile5: > - pop es > - > - jmp LoadFile ; Load the next cluster (if any) > + pop %es > + > + jmp LoadFile /* Load the next cluster (if any) */ > > LoadFile_Done: > - mov dl,BYTE [BYTE bp+BootDrive] ; Load the boot drive into DL > - mov dh,[BootPartition] ; Load the boot partition into DH > - > - push 0 ; push segment (0x0000) > - mov bx, [0x8000 + 0xA8] ; load the RVA of the EntryPoint into eax > - add bx, 0x8000 ; RVA -> VA and skip 3 bytes (jump to fathelper code) > - push bx ; push offset > - retf ; Transfer control to FreeLoader > - > -; Reads the entire FAT into memory at 7000:0000 > + mov %dl,BYTE [%bp+BootDrive] /* Load the boot drive into DL */ > + mov %dh,[BootPartition] /* Load the boot partition into DH */ > + > + push 0 /* push segment (0x0000) */ > + mov %bx, [0x80A8] /* load the RVA of the EntryPoint into eax */ > + add %bx, 0x8000 /* RVA -> VA and skip 3 bytes (jump to fathelper code) */ > + push %bx /* push offset */ > + retf /* Transfer control to FreeLoader */ > + > +// Reads the entire FAT into memory at 7000:0000 > ReadFatIntoMemory: > - mov ax,WORD [BYTE bp+HiddenSectors] > - mov dx,WORD [BYTE bp+HiddenSectors+2] > - add ax,WORD [BYTE bp+ReservedSectors] > - adc dx,byte 0 > - mov cx,WORD [BYTE bp+SectorsPerFat] > - mov bx,7000h > - mov es,bx > - xor bx,bx > - call [bp-ReadSectorsOffset] > - ret > - > - > -; Returns the FAT entry for a given cluster number for 16-bit FAT > -; On entry AX has cluster number > -; On return AX has FAT entry for that cluster > + mov %ax,WORD [%bp+HiddenSectors] > + mov %dx,WORD [%bp+HiddenSectors+2] > + add %ax,WORD [%bp+ReservedSectors] > + adc %dx,0 > + mov %cx,WORD [%bp+SectorsPerFat] > + mov %bx,0x7000 > + mov %es,%bx > + xor %bx,%bx > + call [%bp-ReadSectorsOffset] > + ret > + > + > +// Returns the FAT entry for a given cluster number for 16-bit FAT > +// On entry AX has cluster number > +// On return AX has FAT entry for that cluster > GetFatEntry16: > > - mov cx,2 ; AX = AX * 2 (since FAT16 entries are 2 bytes) > - mul cx > - shl dx,12 > - > - mov bx,7000h > - add bx,dx > - mov es,bx > - mov bx,ax ; Restore FAT entry offset > - mov ax,WORD [es:bx] ; Get FAT entry > - > - ret > - > - > -; Returns the FAT entry for a given cluster number for 12-bit FAT > -; On entry AX has cluster number > -; On return AX has FAT entry for that cluster > + mov %cx,2 /* AX = AX * 2 (since FAT16 entries are 2 bytes) */ > + mul %cx > + shl %dx,12 > + > + mov %bx,0x7000 > + add %bx,%dx > + mov %es,%bx > + mov %bx,%ax /* Restore FAT entry offset */ > + es mov %ax,WORD [%bx] /* Get FAT entry */ > + > + ret > + > + > +// Returns the FAT entry for a given cluster number for 12-bit FAT > +// On entry AX has cluster number > +// On return AX has FAT entry for that cluster > GetFatEntry12: > > - push ax > - mov cx,ax > - shr ax,1 > - add ax,cx ; AX = AX * 1.5 (AX = AX + (AX / 2)) (since FAT12 entries are 12 bits) > - > - mov bx,7000h > - mov es,bx > - mov bx,ax ; Put FAT entry offset into BX > - mov ax,WORD [es:bx] ; Get FAT entry > - pop cx ; Get cluster number from stack > - and cx,1 > + push %ax > + mov %cx,%ax > + shr %ax,1 > + add %ax,%cx /* AX = AX * 1.5 (AX = AX + (AX / 2)) (since FAT12 entries are 12 bits) */ > + > + mov %bx,0x7000 > + mov %es,%bx > + mov %bx,%ax /* Put FAT entry offset into BX */ > + es mov %ax,WORD [%bx] /* Get FAT entry */ > + pop %cx /* Get cluster number from stack */ > + and %cx,1 > jz UseLow12Bits > - and ax,0fff0h > - shr ax,4 > + and %ax,0xfff0 > + shr %ax,4 > jmp GetFatEntry12_Done > > UseLow12Bits: > - and ax,0fffh > + and %ax,0x0fff > > GetFatEntry12_Done: > > ret > > > -; Returns CF = 1 if this is a FAT12 file system > -; Otherwise CF = 0 for FAT16 > +// Returns CF = 1 if this is a FAT12 file system > +// Otherwise CF = 0 for FAT16 > IsFat12: > > - mov ebx,DWORD [BYTE bp-DataAreaStartLow] > - ; EBX now has the number of the starting sector of the data area > - ; starting from the beginning of the disk, so subtrace hidden sectors > - sub ebx,DWORD [BYTE bp+HiddenSectors] > - > - > - xor eax,eax > - mov ax,WORD [BYTE bp+TotalSectors] > - cmp ax,byte 0 > + mov %ebx,DWORD [%bp-DataAreaStartLow] > + // EBX now has the number of the starting sector of the data area > + // starting from the beginning of the disk, so subtrace hidden sectors > + sub %ebx,DWORD [%bp+HiddenSectors] > + > + > + xor %eax,%eax > + mov %ax,WORD [%bp+TotalSectors] > + cmp %ax,0 > jnz IsFat12_2 > - mov eax,DWORD [BYTE bp+TotalSectorsBig] > - > - ; EAX now contains the number of sectors on the volume > + mov %eax,DWORD [%bp+TotalSectorsBig] > + > + // EAX now contains the number of sectors on the volume > > IsFat12_2: > - sub eax,ebx ; Subtract data area start sector > - xor edx,edx ; from total sectors of volume > - > - ; EDX:EAX now contains the number of data sectors on the volume > - movzx ebx,BYTE [BYTE bp+SectsPerCluster] > - div ebx > - ; EAX now has the number of clusters on the volume > + sub %eax,%ebx /* Subtract data area start sector */ > + xor %edx,%edx /* from total sectors of volume */ > + > + // EDX:EAX now contains the number of data sectors on the volume > + xor %ebx,%ebx > + mov %bl,BYTE [%bp+SectsPerCluster] > + div %ebx > + // EAX now has the number of clusters on the volume > stc > - cmp eax,4085 > + cmp %eax,4085 > jb IsFat12_Done > clc > > @@ -229,7 +225,9 @@ > > > > -msgLoading db 'Loading FreeLoader...',0dh,0ah,0 > - > - times 510-($-$$) db 0 ; Pad to 510 bytes > - dw 0aa55h ; BootSector signature > +msgLoading: > + .asciz "Loading FreeLoader...\r\n" > + > + .org 0x1fe > +blockend: > + .word 0x0aa55 /* BootSector signature */ > > Removed: branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm > URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/boot/freeldr/free… > ============================================================================== > --- branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm [iso-8859-1] (original) > +++ branches/cmake-bringup/boot/freeldr/freeldr/arch/i386/fathelp.asm (removed) > @@ -1,235 +1,0 @@ > -; FATHELP.ASM > -; FAT12/16 Boot Sector Helper Code > -; Copyright (c) 1998, 2001, 2002, 2003 Brian Palmer > - > - > - > -;org 8000h > - > -segment .text > - > -bits 16 > - > - > -BootSectorStackTop equ 0x7bf2 > -DataAreaStartHigh equ 0x2 > -DataAreaStartLow equ 0x4 > -BiosCHSDriveSizeHigh equ 0x6 > -BiosCHSDriveSizeLow equ 0x8 > -BiosCHSDriveSize equ 0x8 > -ReadSectorsOffset equ 0xa > -ReadClusterOffset equ 0xc > -PutCharsOffset equ 0xe > - > -OEMName equ 3 > -BytesPerSector equ 11 > -SectsPerCluster equ 13 > -ReservedSectors equ 14 > -NumberOfFats equ 16 > -MaxRootEntries equ 17 > -TotalSectors equ 19 > -MediaDescriptor equ 21 > -SectorsPerFat equ 22 > -SectorsPerTrack equ 24 > -NumberOfHeads equ 26 > -HiddenSectors equ 28 > -TotalSectorsBig equ 32 > -BootDrive equ 36 > -Reserved equ 37 > -ExtendSig equ 38 > -SerialNumber equ 39 > -VolumeLabel equ 43 > -FileSystem equ 54 > - > -BootPartition equ 0x7dfd > - > - > -; This code will be stored in the first 512 bytes > -; of freeldr.sys. The first 3 bytes will be a jmp > -; instruction to skip past the FAT helper code > -; that is stored in the rest of the 512 bytes. > -; > -; This code is loaded at 0000:8000 so we have to > -; encode a jmp instruction to jump to 0000:8200 > - > -global _mainCRTStartup ; For Mingw32 builds where the linker looks for this symbol > -_mainCRTStartup: > -global start > -start: > - db 0xe9 > - db 0xfd > - db 0x01 > - > -; Now starts the extra boot code that we will store > -; in the first 512 bytes of freeldr.sys. This code > -; allows the FAT12/16 bootsector to navigate the > -; FAT table so that we can still load freeldr.sys > -; even if it is fragmented. > - > - > -FatHelperEntryPoint: > - > - push ax ; First save AX - the start cluster of freeldr.sys > - > - > - ; Display "Loading FreeLoader..." message > - mov esi,msgLoading ; Loading message > - call [bp-PutCharsOffset] ; Display it > - > - > - call ReadFatIntoMemory > - > - pop ax ; Restore AX (start cluster) > - ; AX has start cluster of freeldr.sys > - > - mov bx,800h > - mov es,bx > - > -LoadFile: > - push ax > - call IsFat12 > - pop ax > - jnc LoadFile2 > - cmp ax,0ff8h ; Check to see if this is the last cluster in the chain > - jmp LoadFile3 > -LoadFile2: > - cmp ax,0fff8h > -LoadFile3: > - jae LoadFile_Done ; If so continue, if not then read then next one > - push ax > - xor bx,bx ; Load ROSLDR starting at 0000:8000h > - push es > - call [bp-ReadClusterOffset] > - pop es > - > - xor bx,bx > - mov bl,BYTE [BYTE bp+SectsPerCluster] > - shl bx,5 ; BX = BX * 512 / 16 > - mov ax,es ; Increment the load address by > - add ax,bx ; The size of a cluster > - mov es,ax > - > - call IsFat12 > - pop ax > - push es > - jnc LoadFile4 > - call GetFatEntry12 ; Get the next entry > - jmp LoadFile5 > -LoadFile4: > - call GetFatEntry16 > -LoadFile5: > - pop es > - > - jmp LoadFile ; Load the next cluster (if any) > - > -LoadFile_Done: > - mov dl,BYTE [BYTE bp+BootDrive] ; Load the boot drive into DL > - mov dh,[BootPartition] ; Load the boot partition into DH > - > - push 0 ; push segment (0x0000) > - mov bx, [0x8000 + 0xA8] ; load the RVA of the EntryPoint into eax > - add bx, 0x8000 ; RVA -> VA and skip 3 bytes (jump to fathelper code) > - push bx ; push offset > - retf ; Transfer control to FreeLoader > - > -; Reads the entire FAT into memory at 7000:0000 > -ReadFatIntoMemory: > - mov ax,WORD [BYTE bp+HiddenSectors] > - mov dx,WORD [BYTE bp+HiddenSectors+2] > - add ax,WORD [BYTE bp+ReservedSectors] > - adc dx,byte 0 > - mov cx,WORD [BYTE bp+SectorsPerFat] > - mov bx,7000h > - mov es,bx > - xor bx,bx > - call [bp-ReadSectorsOffset] > - ret > - > - > -; Returns the FAT entry for a given cluster number for 16-bit FAT > -; On entry AX has cluster number > -; On return AX has FAT entry for that cluster > -GetFatEntry16: > - > - mov cx,2 ; AX = AX * 2 (since FAT16 entries are 2 bytes) > - mul cx > - shl dx,12 > - > - mov bx,7000h > - add bx,dx > - mov es,bx > - mov bx,ax ; Restore FAT entry offset > - mov ax,WORD [es:bx] ; Get FAT entry > - > - ret > - > - > -; Returns the FAT entry for a given cluster number for 12-bit FAT > -; On entry AX has cluster number > -; On return AX has FAT entry for that cluster > -GetFatEntry12: > - > - push ax > - mov cx,ax > - shr ax,1 > - add ax,cx ; AX = AX * 1.5 (AX = AX + (AX / 2)) (since FAT12 entries are 12 bits) > - > - mov bx,7000h > - mov es,bx > - mov bx,ax ; Put FAT entry offset into BX > - mov ax,WORD [es:bx] ; Get FAT entry > - pop cx ; Get cluster number from stack > - and cx,1 > - jz UseLow12Bits > - and ax,0fff0h > - shr ax,4 > - jmp GetFatEntry12_Done > - > -UseLow12Bits: > - and ax,0fffh > - > -GetFatEntry12_Done: > - > - ret > - > - > -; Returns CF = 1 if this is a FAT12 file system > -; Otherwise CF = 0 for FAT16 > -IsFat12: > - > - mov ebx,DWORD [BYTE bp-DataAreaStartLow] > - ; EBX now has the number of the starting sector of the data area > - ; starting from the beginning of the disk, so subtrace hidden sectors > - sub ebx,DWORD [BYTE bp+HiddenSectors] > - > - > - xor eax,eax > - mov ax,WORD [BYTE bp+TotalSectors] > - cmp ax,byte 0 > - jnz IsFat12_2 > - mov eax,DWORD [BYTE bp+TotalSectorsBig] > - > - ; EAX now contains the number of sectors on the volume > - > -IsFat12_2: > - sub eax,ebx ; Subtract data area start sector > - xor edx,edx ; from total sectors of volume > - > - ; EDX:EAX now contains the number of data sectors on the volume > - movzx ebx,BYTE [BYTE bp+SectsPerCluster] > - div ebx > - ; EAX now has the number of clusters on the volume > - stc > - cmp eax,4085 > - jb IsFat12_Done > - clc > - > -IsFat12_Done: > - ret > - > - > - > -msgLoading db 'Loading FreeLoader...',0dh,0ah,0 > - > - times 510-($-$$) db 0 ; Pad to 510 bytes > - dw 0aa55h ; BootSector signature > > >

9 11

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev