Re: [ros-dev] NTFS in ReactOS: heise online article

[Thomas Mueller]

>> My idea was to build and use the ROSBE on FreeBSD, NetBSD or Linux to build 
>> the trunk, then install to a USB stick formatted FAT32.

>> Question is whether that could boot.

> In theory, it could. In practice, I'm not that sure, you're really
> dependent on USB. And I'm not sure it's in a that good shape,
> unfortunately...


> Pierre Schweitzer 

I believe FreeDOS can boot from USB if the BIOS supports USB, but then I 
suppose ReactOS, like other non-DOS OSes, does not use the BIOS beyond finding 
the initial boot code.

New developments make ReactOS more interesting, and I might like to test some 
MS-Windows hardware drivers.

I could try to install ReactOS onto a USB stick but might wait until later for 
improvements in USB support.

I must remember that ReactOS 0.3.15 iso burned to CD failed to boot on my 
computers.

If I subsequently want to build application software for ReactOS, I suppose I 
could use Wine under Linux or FreeBSD.

Regarding lack of support for GPT in ReactOS, OpenBSD also fails to support GPT.

Tom


___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] Replacing unsafe TRUE comparisons (Following Re: bool => BOOL)

[Love Nystrom]

On 2014-11-12 19.41, David Quintana (gigaherz) wrote:
It's a common practice to include giant code dumps as attachments 
instead of inlining them in the text of the mail.
It may also be a good idea to provide multiple patches based on 
component, so that different people can take a look at the patches 
relating to their areas of expertise.
If providing one patch per folder is too much work, then at least 
based on the top-level one. applications.patch, dll.patch, 
ntoskrnl.patch, etc. would be much easier to review.


Yes, I know..
But since each of these patches are exceedingly trivial, strongly 
inter-related,

exposes a common bad habit in programming, and this touches practically
every part of the system, I chose to make one big patch this time.

Had the patches been more involved, or fewer,
I would of course have posted them in chunks.

Best Regards
// Love



On 12 November 2014 10:48, Love Nystrom > wrote:


Grep'ing for [ \t]*==[ \t]*TRUE and [ \t]*!=[ \t]*TRUE revealed
some 400 matches..
That's *400 potential malfunctions begging to happen*, as
previously concluded.

If you *must*, for some obscure reason, code an explicit
truth-value comparison,
for God's sake make it (boolVal != FALSE) or (boolVal == FALSE),
which is safe,
because a BOOL has 2^32-2 TRUE values !!!

However, the more efficient "if ( boolVal )" and "if ( !boolVal )"
ought to be *mandatory*.

I do hope nobody will challenge that "if ( boolVal )" equals "if (
boolVal != FALSE )",
and does *not* equal "if ( boolVal == TRUE )", when boolVal is
BOOL or BOOLEAN...

I've patched all those potential errors against the current trunk.
In most cases a simple removal of "== TRUE" was sufficient, however in
asserts I replaced it with "!= FALSE", since that may be clearer
when triggered.
The only places I let it pass was in pure debug strings and comments.

As this is a *fairly extensive patch*, I would very much
appreciate if a
*prioritized regression test* could be run by you guys who do such
things,
since this may actually fix some "mysterious" malfunctions, or
introduce
bugs that did not trigger in my alpha test.

My own alpha test was limited to building and installing it on
VMware Player 6,
and concluding that "it appears to run without obvious malfunctions".
*Actually, when compared to a pre-patch build, one "mysterious"
crash disappeared!*

The patch has been submitted as bug CORE-8799, and is also
included inline in this post.

Best Regards
// Love


[abbrev]
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Re: [ros-dev] [ros-diffs] [jgardou] 65388: [TCPIP] - Comment out an optimisation which doesn't work. Reviews of why would be most appreciated.

[Timo Kreuzer]

tcpip.c:264

/* Keep this list sorted */
InsertHeadList(ListEntry, &OutInstance->ListEntry);

This should probably be InsertTailList(), since you want to insert 
before the current ListEntry



Am 12.11.2014 12:39, schrieb jgar...@svn.reactos.org:

Author: jgardou
Date: Wed Nov 12 11:39:13 2014
New Revision: 65388

URL: http://svn.reactos.org/svn/reactos?rev=65388&view=rev
Log:
[TCPIP]
  - Comment out an optimisation which doesn't work.
Reviews of why would be most appreciated.

Modified:
 branches/tcpip_revolution/drivers/network/tcpip/entities.c

Modified: branches/tcpip_revolution/drivers/network/tcpip/entities.c
URL: 
http://svn.reactos.org/svn/reactos/branches/tcpip_revolution/drivers/network/tcpip/entities.c?rev=65388&r1=65387&r2=65388&view=diff
==
--- branches/tcpip_revolution/drivers/network/tcpip/entities.c  [iso-8859-1] 
(original)
+++ branches/tcpip_revolution/drivers/network/tcpip/entities.c  [iso-8859-1] 
Wed Nov 12 11:39:13 2014
@@ -309,9 +309,11 @@
  return STATUS_SUCCESS;
  }
  
+#if 0

  /* The list is sorted, so we can cut the loop a bit */
  if (ID.tei_instance < Instance->InstanceId.tei_instance)
  break;
+#endif
  
  ListEntry = ListEntry->Flink;

  }






___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[ros-dev] Replacing unsafe TRUE comparisons (Following Re: bool => BOOL)

[Love Nystrom]

Grep'ing for [ \t]*==[ \t]*TRUE and [ \t]*!=[ \t]*TRUE revealed some 400 
matches..
That's *400 potential malfunctions begging to happen*, as previously 
concluded.


If you *must*, for some obscure reason, code an explicit truth-value 
comparison,
for God's sake make it (boolVal != FALSE) or (boolVal == FALSE), which 
is safe,

because a BOOL has 2^32-2 TRUE values !!!

However, the more efficient "if ( boolVal )" and "if ( !boolVal )" ought 
to be *mandatory*.


I do hope nobody will challenge that "if ( boolVal )" equals "if ( 
boolVal != FALSE )",
and does *not* equal "if ( boolVal == TRUE )", when boolVal is BOOL or 
BOOLEAN...


I've patched all those potential errors against the current trunk.
In most cases a simple removal of "== TRUE" was sufficient, however in
asserts I replaced it with "!= FALSE", since that may be clearer when 
triggered.

The only places I let it pass was in pure debug strings and comments.

As this is a *fairly extensive patch*, I would very much appreciate if a
*prioritized regression test* could be run by you guys who do such things,
since this may actually fix some "mysterious" malfunctions, or introduce
bugs that did not trigger in my alpha test.

My own alpha test was limited to building and installing it on VMware 
Player 6,

and concluding that "it appears to run without obvious malfunctions".
*Actually, when compared to a pre-patch build, one "mysterious" crash 
disappeared!*


The patch has been submitted as bug CORE-8799, and is also included 
inline in this post.


Best Regards
// Love

===

Index: base/applications/calc/utl.c
===
--- base/applications/calc/utl.c(revision 65379)
+++ base/applications/calc/utl.c(working copy)
@@ -19,7 +19,7 @@
 #define MAX_LD_WIDTH16
 /* calculate the width of integer number */
 width = (rpn->f==0) ? 1 : (int)log10(fabs(rpn->f))+1;
-if (calc.sci_out == TRUE || width > MAX_LD_WIDTH || width < 
-MAX_LD_WIDTH)

+if (calc.sci_out || width > MAX_LD_WIDTH || width < -MAX_LD_WIDTH)
 _stprintf(buffer, TEXT("%#e"), rpn->f);
 else {
 TCHAR *ptr, *dst;
Index: base/applications/calc/utl_mpfr.c
===
--- base/applications/calc/utl_mpfr.c(revision 65379)
+++ base/applications/calc/utl_mpfr.c(working copy)
@@ -39,7 +39,7 @@
 width = 1 + mpfr_get_si(t, MPFR_DEFAULT_RND);
 mpfr_clear(t);
 }
-if (calc.sci_out == TRUE || width > max_ld_width || width < 
-max_ld_width)

+if (calc.sci_out || width > max_ld_width || width < -max_ld_width)
 ptr = temp + gmp_sprintf(temp, "%*.*#Fe", 1, max_ld_width, 
ff);

 else {
 ptr = temp + gmp_sprintf(temp, "%#*.*Ff", width, 
((max_ld_width-width-1)>=0) ? max_ld_width-width-1 : 0, ff);

Index: base/applications/calc/winmain.c
===
--- base/applications/calc/winmain.c(revision 65379)
+++ base/applications/calc/winmain.c(working copy)
@@ -290,7 +290,7 @@

 _stprintf(buf, TEXT("%lu"), calc.layout);
 WriteProfileString(TEXT("SciCalc"), TEXT("layout"), buf);
-WriteProfileString(TEXT("SciCalc"), TEXT("UseSep"), 
(calc.usesep==TRUE) ? TEXT("1") : TEXT("0"));
+WriteProfileString(TEXT("SciCalc"), TEXT("UseSep"), (calc.usesep) ? 
TEXT("1") : TEXT("0"));

 }

 static LRESULT post_key_press(LPARAM lParam, WORD idc)
@@ -1107,7 +1107,7 @@

 static void run_fe(calc_number_t *number)
 {
-calc.sci_out = ((calc.sci_out == TRUE) ? FALSE : TRUE);
+calc.sci_out = ((calc.sci_out) ? FALSE : TRUE);
 }

 static void handle_context_menu(HWND hWnd, WPARAM wp, LPARAM lp)
Index: base/applications/charmap/settings.c
===
--- base/applications/charmap/settings.c(revision 65379)
+++ base/applications/charmap/settings.c(working copy)
@@ -91,7 +91,7 @@

 RegQueryValueEx(hKey, _T("Advanced"), NULL, &type, 
(LPBYTE)&dwAdvanChecked, &size);


-if(dwAdvanChecked == TRUE)
+if(dwAdvanChecked)
 SendDlgItemMessage(hCharmapDlg, IDC_CHECK_ADVANCED, 
BM_CLICK, MF_CHECKED, 0);


 RegCloseKey(hKey);
Index: base/applications/cmdutils/more/more.c
===
--- base/applications/cmdutils/more/more.c(revision 65379)
+++ base/applications/cmdutils/more/more.c(working copy)
@@ -63,7 +63,7 @@
{
   ReadConsoleInput (hKeyboard, &ir, 1, &dwRead);
   if ((ir.EventType == KEY_EVENT) &&
- (ir.Event.KeyEvent.bKeyDown == TRUE))
+ (ir.Event.KeyEvent.bKeyDown))
  return;
}
while (TRUE);
Index: base/applications/mscutils/servman/start.c
===
--- base/