DOS ain't dead

> > > Ah, I had forgotten (since I've never used Plan9) that they were a bit
> > > different. So yeah, perhaps by default they didn't need (or want) a
> > > "full" preprocessor, hence the POSIX environment add-on.
> >
> > I'm not sure what you're talking about.
>
> http://man.cat-v.org/plan_9/1/cpp
>
> "The standard Plan 9 C compilers do not use cpp; they contain their own
> simple but adequate preprocessor, so cpp is usually superfluous."
>
> http://plan9.bell-labs.com/sys/doc/comp.html
>
> "The compilers include an integrated preprocessor that accepts the familiar
> #include, #define for macros both with and without arguments, #undef,
> #line, #ifdef, #ifndef, and #endif. It supports neither #if nor ##,
> although it does honor a few #pragmas. The #if directive was omitted
> because it greatly complicates the preprocessor, is never necessary, and is
> usually abused. Conditional compilation in general makes code hard to
> understand; the Plan 9 source uses it sparingly. Also, because the
> compilers remove dead code, regular if statements with constant conditions
> are more readable equivalents to many #ifs. To compile imported code
> ineluctably fouled by #if there is a separate command, /bin/cpp, that
> implements the complete ANSI C preprocessor specification."

I've read all that before. However, I've missed or forgotten the statement "The compilers include an integrated preprocessor", which may explain certain issues (bugs, etc) in their standalone preprocessor. They simply didn't care much about it and it somehow worked for them in those rare cases they needed it.

As for "perhaps by default they didn't need (or want) a "full" preprocessor, hence the POSIX environment add-on", #if and ## are standard in C and not specific to POSIX. This is why I wasn't sure what you meant.

> > I don't think licenses can travel backwards and then forward again in
> time.
> > The diff between LCC and Plan9 is not GPL'd.
>
> How big a difference (and advantage) is it? Surely you can handle the
> original (worse code but better license).

The diff is not too big or complex, but I'll have to review it because it seems to also fix a few issues. Right now I'm cleaning up and ANSI-C-fying the original code (duplicate work), so it can compile with a standard compiler and minimally function. Then I'll make further fixes and improvements with a few specific for Smaller C.

Alex

> > > Sadly, some people have no imagination, certainly regarding DOS.
> >
> > My compiler targets Windows, Linux and RetroBSD as well, so, it's either
> > the compiler or all four OSes. :)
>
> You've done a very impressive job, so if your compiler isn't being
> significantly tested by outside developers, then I blame them, not you.
> That's what I meant. Developers can be narrow-minded, stuck in their ways
> ("all the world's a VAX").

Thanks. :)

> Plus I think a lot of projects are too non-portable (or at least haven't
> well isolated the system-specific stuff). That probably doesn't help.

The standard C is missing a few important things, which make it difficult to make a fully portable compiler. E.g. there's only system() for you to execute some other program. But the standard does not even require system() to return back to the caller and it doesn't tell how to interpret the returned value. And there's nothing in the standard about special symbols and various quotation and escaping mechanisms of the "command processor" (AKA shell). However, in DOS, Windows and Linux, system() normally returns and (with the exception of DOS's COMMAND.COM) it returns 0 on success and non-zero on failure. So, if you're conservative and cautious, you can use system() on selected platforms, perhaps only with minor platform specialization and trickery.

> > > Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> > > (relatively) easy to port.
> >
> > I haven't seen it, but I have doubts.
>
> It's fairly small, but it too is probably very POSIX heavy (or maybe relies
> on other weird stuff, alloca??). Dunno, maybe a bad suggestion, I too
> haven't looked closely.

If I'm unhappy with Plan9's, I may take a look.

> > I didn't know about that. I have plan9.iso.bz2 downloaded in January
> 2015
> > from Lucent.
>
> http://akaros.cs.berkeley.edu/files/Plan9License says this:
>
> "The University of California, Berkeley, has been authorised by
> Alcatel-Lucent to release all Plan 9 software previously governed by
> the Lucent Public License, Version 1.02 under the GNU General
> Public License, Version 2."
>
> So if you're worried about licensing, use that version. It can't be much
> worse than LCC's fork, can it?

Not significantly.

Alex

> I've read all that before. However, I've missed or forgotten the statement
> "The compilers include an integrated preprocessor", which may explain
> certain issues (bugs, etc) in their standalone preprocessor. They simply
> didn't care much about it and it somehow worked for them in those rare
> cases they needed it.
>
> As for "perhaps by default they didn't need (or want) a "full"
> preprocessor, hence the POSIX environment add-on", #if and ## are standard
> in C and not specific to POSIX. This is why I wasn't sure what you meant.

Even though I've never used it, I was referring to this:

APE ? The ANSI/POSIX Environment

> Btw, did I tell you that Smaller C has basic floating point support now?

I did notice already on Github, but none of my wimpy code needs it.

> (I shouldn't probably mention on this forum that it can also make Windows
> GUI apps (there's a small clock demo for SDL2.dll))

I saw that too but never tried it. However, since you mentioned it, just FYI ....

At one time the remake of Atomiks (by Mateusz Viste), at least the Win32 .EXE using SDL 1.2, ran under HX/DOS. So ....

> > > > Isn't ancient GCC 2.7's CPP fairly small? I imagine that would be
> > > > (relatively) easy to port.
> > >
> > > I haven't seen it, but I have doubts.
> >
> > It's fairly small, but it too is probably very POSIX heavy (or maybe
> relies
> > on other weird stuff, alloca??). Dunno, maybe a bad suggestion, I too
> > haven't looked closely.
>
> If I'm unhappy with Plan9's, I may take a look.

So, I've cleaned up and ANSI-C-fied the original Plan9's preprocessor and decided to compare it with the LCC version. It's funny, but there are bugs in both as can be seen when feeding them examples from the C standard. LCC aims at fixing some of them, but has a mixed success. It fixes a couple, fails to fix another and on some input just hangs. I might spend some cycles to investigate and fix some of these, but it's a bit of a bummer. I had higher expectations for this preprocessor.

There's another one (ucpp) and it seems to pass those tests and it's BSD-licensed, but it's larger and needs to be split into more .c files for compilation with Smaller C (alternatively, smlrc may be recompiled to accommodate for larger .c files).

We'll see...

Alex

If you're not a fan of that other ucpp, you can try my copy which is minimally changed from Thomas P's version (make file only, a couple bug fixes, easy to embed). Btw, I'm the upstream the other ucpp links to on code.google.com.

https://github.com/lpsantil/ucpp

> If you're not a fan of that other ucpp, you can try my copy which is
> minimally changed from Thomas P's version (make file only, a couple bug
> fixes, easy to embed). Btw, I'm the upstream the other ucpp links to on
> code.google.com.
>
> https://github.com/lpsantil/ucpp

I've actually almost finished integrating it with Smaller C. You can get the work-in-progress from a temporary branch, ucpp (will disappear once merged into master). It seems to be working.

> I've actually almost finished integrating it with Smaller C.
> It seems to be working.

Nice work! Good job!

> > I've actually almost finished integrating it with Smaller C.
> > It seems to be working.
>
> Nice work! Good job!

Thanks! :)

BTW, I've never looked closely, but I'm not sure your tmpfile handling works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%, instead preferring current dir (e.g. "@.\TMP00002.$$$").

Even worse, although I admit this is an extremely rare scenario, when I boot up my old P4 (using PLoP Boot Manager), there is no real hard disk, thus "C:\" is (read-only) USB, which of course confuses smlrcc (despite %TEMP%, %TMP%, %TMPDIR% pointing to RAM disk!!), causing a critical error.

(Honestly, I don't know, this could be some rare FreeDOS bug/compatibility quirk. I vaguely remember some weirdness in findfirst re: dirs.)

Maybe "-tmpdir" option to override auto-detection would be easier?

EDIT: "g:" and "g:\" both work okay, but (default) "g:\temp" doesn't (nor do several other variations), if that helps narrow things down.

> BTW, I've never looked closely, but I'm not sure your tmpfile handling
> works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%,
> instead preferring current dir (e.g. "@.\TMP00002.$$$").
>
> Even worse, although I admit this is an extremely rare scenario, when I
> boot up my old P4 (using PLoP Boot Manager), there is no real hard disk,
> thus "C:\" is (read-only) USB, which of course confuses smlrcc (despite
> %TEMP%, %TMP%, %TMPDIR% pointing to RAM disk!!), causing a critical error.
>
> (Honestly, I don't know, this could be some rare FreeDOS bug/compatibility
> quirk. I vaguely remember some weirdness in findfirst re: dirs.)

I'll take a look later this week.

> Maybe "-tmpdir" option to override auto-detection would be easier?

I don't think this should be needed once the issue is understood and resolved.

> EDIT: "g:" and "g:\" both work okay, but (default) "g:\temp" doesn't (nor
> do several other variations), if that helps narrow things down.

What do you mean by that? Are you saying that setting TEMP=g:\ or TEMP=g: works, while TEMP=g:\temp doesn't?

> BTW, I've never looked closely, but I'm not sure your tmpfile handling
> works correctly in FreeDOS. It doesn't seem to find %TEMP% or %TMP%,

It turns out I'd messed up slashes when passing paths to function 0x4300 to see if %TEMP% exists as a directory. C:\ and C:\FOO are OK, but C: and C:\FOO\ are not. Since I always had writable C: with enough space and on Windows smlrcc does not invoke tmpfile(), I never saw the problem. It's also possible that Windows and/or DOSBox was too forgiving when I looked at this some time ago and saw no obvious problem.

Try the updated binaries and libraries.

> Try the updated binaries and libraries.

Some quick testing under VM (FreeDOS) shows that it works okay now.

(This is almost too trivial or redundant to even mention, but alas ....)

Your main Github page points to this (now broken) link:

CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/

But you can still find it on DJGPP mirrors under /current/v2misc/ .

It's also recently been mirrored on iBiblio for FreeDOS.

Another related issue is your wiki section regarding this:

> -maxheap <number> Specifies the maximum heap size (in bytes)
> for DPMI programs. To be used with option -dosp. If the option isn't
> given, the linker assumes 16777216 (16MB). The number can be decimal,
> hex or octal. The program may receive a heap whose size is smaller
> than this number (e.g. if there isn't this much free DPMI memory;
> Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> is known to limit DPMI memory to 16MB).

I haven't used 32-bit Windows in several years, since my Vista laptop died, but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with a registry hack. "Add registry entry 'DpmiLimit' with large enough
value to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW ".

> (This is almost too trivial or redundant to even mention, but alas ....)
>
> Your main Github page points to this (now broken) link:
>
> CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/

The entire homer isn't accessible. Odd.

> But you can still find it on DJGPP mirrors under
> /current/v2misc/
> .
>
> It's also recently been mirrored on
> iBiblio
> for FreeDOS.

Yeah, I can link to e.g. DJGPP's servers.

> Another related issue is your wiki section regarding this:
>
> > -maxheap <number> Specifies the maximum heap size (in bytes)
> > for DPMI programs. To be used with option -dosp. If the option isn't
> > given, the linker assumes 16777216 (16MB). The number can be decimal,
> > hex or octal. The program may receive a heap whose size is smaller
> > than this number (e.g. if there isn't this much free DPMI memory;
> > Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> > is known to limit DPMI memory to 16MB).
>
> I haven't used 32-bit Windows in several years, since my Vista laptop died,
> but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with a
> registry hack. "Add registry entry 'DpmiLimit' with large enough
> value to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
> ".

It's probably a typo (I want to check with my 32-bit Windows 7). I was probably thinking of DOSBox at the time or about the -maxheap default.

> > (This is almost too trivial or redundant to even mention, but alas ....)
> >
> > Your main Github page points to this (now broken) link:
> >
> > CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/
>
> The entire homer isn't accessible. Odd.
>
> > But you can still find it on DJGPP mirrors under
> >
> /current/v2misc/
> > .
> >
> > It's also recently been mirrored on
> >
> iBiblio
> > for FreeDOS.
>
> Yeah, I can link to e.g. DJGPP's servers.

I wrote an e-mail to the author to see if he's going to upload it anywhere else. Mentioned github.

> > Another related issue is your wiki section regarding this:
> >
> > > -maxheap <number> Specifies the maximum heap size (in bytes)
> > > for DPMI programs. To be used with option -dosp. If the option isn't
> > > given, the linker assumes 16777216 (16MB). The number can be decimal,
> > > hex or octal. The program may receive a heap whose size is smaller
> > > than this number (e.g. if there isn't this much free DPMI memory;
> > > Windows XP can provide up to ~1GB of DPMI memory while Windows Vista/7
> > > is known to limit DPMI memory to 16MB).
> >
> > I haven't used 32-bit Windows in several years, since my Vista laptop
> died,
> > but AFAIK the limit was (default) 32 MB, only adjustable (with SP1) with
> a
> > registry hack. "Add registry entry 'DpmiLimit' with large enough
> > value to
> Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
> > ".
>
> It's probably a typo (I want to check with my 32-bit Windows 7). I was
> probably thinking of DOSBox at the time or about the -maxheap default.

Just checked, indeed 32MB is the default DPMI max under Windows 7. The number is updated, thanks!

> > >
> > > Your main Github page points to this (now broken) link:
> > >
> > > CWSDPMI: http://homer.rice.edu/~sandmann/cwsdpmi/
> >
> > The entire homer isn't accessible. Odd.
> >
> > > But you can still find it on DJGPP mirrors under
> > >
> >
> /current/v2misc/
> > > .
> > >
> > > It's also recently been mirrored on
> > >
> >
> iBiblio
> > > for FreeDOS.
> >
> > Yeah, I can link to e.g. DJGPP's servers.
>
> I wrote an e-mail to the author to see if he's going to upload it anywhere
> else. Mentioned github.

Just got an e-mail from Charles:

----8<----
http://sandmann.dotster.com/index1.html
http://sandmann.dotster.com/cwsdpmi/

(I am working on a nicer DNS / redirect)

I have just been exceptionally busy. This will also restore the win2k pages and some other things I have provided in the past. Perhaps we should consider what is really important and also mirror on DJ?s server.

BTW, my EarthLink email addresses are probably dying end of this month, so I need to set up a replacement on one of my domains (but I need to change about 200 email pointers first).
----8<----

So, things may change again.

> news://comp.os.msdos.programmer on Wed 07 Sep 2016
>
> I don't remember if my compiler's output assembles with
> jump optimization disabled. It might not. I know that
> old versions of NASM used not to assemble it because by
> default NASM would not extend conditional jumps beyond
> the short -128/+127 range.

Yes, if "cpu 8086" is used, even with -O0, it will still workaround this architectural limit with two jumps behind the scenes.

But does your compiler need 8086? I thought it was 386+ only? You don't have such range limits in 386 jumps.

So I have no idea if you can speed up your tests by "set NASMENV=-O0" or not. Try it and see. At least one of my simple programs still compiled and ran okay with -O0.

> > news://comp.os.msdos.programmer on Wed 07 Sep 2016
> >
> > I don't remember if my compiler's output assembles with
> > jump optimization disabled. It might not. I know that
> > old versions of NASM used not to assemble it because by
> > default NASM would not extend conditional jumps beyond
> > the short -128/+127 range.
>
> Yes, if "cpu 8086" is used, even with -O0, it will still workaround this
> architectural limit with two jumps behind the scenes.
>
> But does your compiler need 8086? I thought it was 386+ only? You don't
> have such range limits in 386 jumps.

It is 386+ only. But *old* NASM wouldn't assemble the compiler output.

> So I have no idea if you can speed up your tests by "set NASMENV=-O0" or
> not. Try it and see. At least one of my simple programs still compiled and
> ran okay with -O0.

It helps a tiny bit.

Compiling main compiler file for Windows under Windows:

Using NASM (the default; no NASMENV):
smlrcc -c smlrc.c
8 seconds

Using NASM (the default; NASMENV=-O0):
smlrcc -c smlrc.c
5 seconds

Using YASM:
smlrcc -c smlrc.c -asm yasm
1 second

Using FASM + n2f:
smlrcc -c smlrc.c -asm n2f
1 second

The difference between assemblers is huge as you can see.

> > So I have no idea if you can speed up your tests by "set NASMENV=-O0"
>
> It helps a tiny bit.

So what about using "-a"? I haven't tested it, but they claim its
faster:

http://www.nasm.us/xdoc/2.13.01/html/nasmdoc2.html#section-2.1.21

> If NASM is being used as the back end to a compiler, it might
> be desirable to suppress preprocessing completely and assume
> the compiler has already done it, to save time and increase
> compilation speeds. The -a option, requiring no argument,
> instructs NASM to replace its powerful preprocessor with a
> stub preprocessor which does nothing.

> So what about using "-a"? I haven't tested it, but they claim its
> faster:

No, it won't work ... by default, without minor fixes:

http://www.nasm.us/xdoc/2.13.01/html/nasmdoc6.html

> Primitive directives are enclosed in square brackets;
> user-level directives are not.

So "bits", "section", "global", "extern", etc. need to be surrounded by square brackets, e.g. "[bits 16]" in order for "-a" to not error out.

Then it seems to assemble identically to before.

Someone on freedos-user was mentioning DeSmet C (which was GPL'd several years ago), hinting that we should make a package for FDNPKG. But it's a somewhat limited toolset, and I think SmallerC would make a better package. Would that be okay with you if I made one? It would go in the Software List under Development, mirrored on iBiblio.

In other news, looks like GCC 8 will support "bugfixed" C17.

In still other news, the OpenWatcom 2.0-pre snapshot has been updated very recently.

In annoying (but unsurprising) news, VirusTotal claims to find a trojan in your Win32 PE/.EXE files (under binw). Actually, MS Security Essentials deleted my local .ZIP while I was just listing the files in it! So I had to go to "Settings" and add it to "Excluded files and locations". It's all too common with "exotic" PE/.EXE files.

> Someone on freedos-user was mentioning DeSmet
> C (which was GPL'd several years ago), hinting that we should make a
> package for
> FDNPKG.

There's also "Pacific C for MS-DOS, v7.51" in case it's forgotten.

> But it's a somewhat limited toolset, and I think SmallerC would
> make a better package. Would that be okay with you if I made one? It would
> go in the Software List under
> Development,
> mirrored on iBiblio.

Include the project GitHub URL and the SHA of the top commit somewhere in the package description, so the package can be traced back if needed as I don't maintain a version in the binaries. Also, it's probably a good idea to include the project wiki pages into the package since there's no /? or --help option in the binaries and somehow those wiki pages are not really part of the project (you don't get them in the .zip file downloaded from gitHub or if you do "git pull" on the project).

> In other news, looks like GCC 8 will support "bugfixed"
> C17.
>
> In still other news, the OpenWatcom 2.0-pre
> snapshot
> has been updated very recently.
>
> In annoying (but unsurprising) news,
> VirusTotal
> claims to find a trojan in your Win32 PE/.EXE files (under binw).

Imbeciles. So much for all the AI/ML/etc hype.

> Actually,
> MS Security Essentials deleted my local .ZIP while I was just listing the
> files in it! So I had to go to "Settings" and add it to "Excluded files and
> locations". It's all too common with "exotic" PE/.EXE files.

Um... I had the project directory excluded on my Windows 7 because it was slowing things down, but I just removed the exclusion and scanned the directory with Security Essentials and all was OK. The virus/malware definitions were last updated yesterday (version 1.257.257.0). What's on your end?

> There's also "Pacific C for MS-DOS, v7.51" in case it's forgotten.

I've used it, but I suspect OpenWatcom is better. Then again, you found some "scary" bugs (IIRC), so maybe you think otherwise.

> > But it's a somewhat limited toolset, and I think SmallerC would
> > make a better package. Would that be okay with you if I made one?
> > It would go in the Software List under Development, mirrored on iBiblio.
>
> Include the project GitHub URL and the SHA of the top commit somewhere in
> the package description, so the package can be traced back if needed as I
> don't maintain a version in the binaries.

Sounds reasonable.

> Also, it's probably a good idea to include the project wiki pages
> into the package since there's no /? or --help option in the binaries
> and somehow those wiki pages are not really part of the project
> (you don't get them in the .zip file downloaded from gitHub

Sounds tedious, but I'll try (maybe).

> > In annoying (but unsurprising) news, VirusTotal claims to find
> a trojan in your Win32 PE/.EXE files (under binw).
>
> Imbeciles. So much for all the AI/ML/etc hype.

I've had this problem over a dozen times over the years with various tools. It's just bad heuristics, overzealous detection of anything atypical.

> > Actually, MS Security Essentials deleted my local .ZIP
> while I was just listing the files in it! So I had to go to
> "Settings" and add it to "Excluded files and locations".
>
> Um... I had the project directory excluded on my Windows 7 because it was
> slowing things down, but I just removed the exclusion and scanned the
> directory with Security Essentials and all was OK. The virus/malware
> definitions were last updated yesterday (version 1.257.257.0). What's on
> your end?

I'm on the wrong machine right now, but I did update the definitions yesterday. But I'm not imagining this, it definitely deleted it, ugh. Even after having similar problems like this, it's still annoying.

On this machine, I don't have that installed, only Avast, and even it whines, even after updating. So I just now reported your .ZIP as false positive, hoping they'll fix their error (and maybe it will propagate to other databases).

If it makes you feel any better, out of morbid curiosity, I also submitted an innocuous .ZIP of mine to VirusTotal, and it claimed to find ".BAT viruses" (when really they were just analogous to simple shell scripts using sed).

> On this machine, I don't have that installed, only Avast, and even it
> whines

Even old Firefox on this ancient Puppy Linux is whining, so I had to manually "Unblock" just to download it from Github.

Just as an experiment, I changed the useless "cannot be run in DOS" stub message in one PE/.EXE, and that reduced some (but not all) warnings. So that's how stupid some of them are, even changing something simple like useless text avoids "detection". The obvious red flags (to us) are claims of "generic" or "heuristic", which are often bogus.

> > On this machine, I don't have that installed, only Avast, and even it
> > whines
>
> Even old Firefox on this ancient Puppy Linux is whining, so I had to
> manually "Unblock" just to download it from Github.
>
> Just as an experiment, I changed the useless "cannot be run in DOS" stub
> message in one PE/.EXE, and that reduced some (but not all) warnings. So
> that's how stupid some of them are, even changing something simple like
> useless text avoids "detection". The obvious red flags (to us) are claims
> of "generic" or "heuristic", which are often bogus.

I just recompiled the five executables with OW 1.9 and mingw (gcc 4.8.2) and the results are significantly better:
OW
mingw

This doesn't tell us what it is that that stupid virusware doesn't like. MZ stub? Date/time stamp? Zero checksum? Linker version? Stack & heap sizes? PE header size? Lack of imports from the brain-dead msvcrt.dll? Import entries in .data instead of a section of their own? And there's no guarantee this problem won't come up again even if the format changes to please the virusware of today.

> virusware of today.

Rather, scareware.

> On this machine, I don't have that installed, only Avast, and even it
> whines, even after updating. So I just now reported your .ZIP as false
> positive, hoping they'll fix their error (and maybe it will propagate to
> other databases).

(I hate to pollute your thread with this, it's almost off-topic.)

<rant>

Sadly, they still haven't fixed their false detection. At least, "Reanalyze" on VirusTotal still shows Avast as saying "Win32:Malware-gen" (where presumably "gen" means "generic", aka heuristic/guess). 12 days later, sigh.

Maybe I shouldn't complain. It's a thankless job, there are thousands of new malwares coming out every day. Plus, I don't pay for this antivirus, it's freeware. So it's not like it's an easy job or anything special I deserve.

But this situation sucks. If you're going to flag with buggy heuristics (which I don't recommend, for obvious reasons), you have to be somewhat diligent in fixing false positives.

</rant>

On the bright side (sarcasm), even rr's (Win32) UPXDUMP.EXE is apparently suspicious to Avast. Here I was naive and thought it was too vanilla to flag, but nope! I should've known after all the other false positives I've gotten over the years. I know it's typical Internet blowhard to rant and say, "I'm uninstalling!", but maybe that would be best. There's only so many exceptions you can make before the whole thing is more of a nuisance than a solution.

Actually, the simplest answer is: Settings, Enable CyberCapture, change from "always block it" to "allow me to decide". (It previously said it sent it to the labs for analysis, but I have low expectations.)

> > On this machine, I don't have that installed, only Avast, and even it
> > whines, even after updating. So I just now reported your .ZIP as false
> > positive, hoping they'll fix their error (and maybe it will propagate to
> > other databases).
>
> (I hate to pollute your thread with this, it's almost off-topic.)
>
> <rant>
>
> Sadly, they still haven't fixed their false detection. At least,
> "Reanalyze" on VirusTotal still shows Avast as saying "Win32:Malware-gen"
> (where presumably "gen" means "generic", aka heuristic/guess). 12 days
> later, sigh.
>
...
> </rant>
> ...

I've spent a few hours playing with:
- MZ header (used the ones from mingw and OW)
- PE header meta info (versions from mingw and OW, different time stamp)
- PE header size (set to more common 1024 instead of 4096 and saving 3KB in total size)
and nothing helped.

For a good measure I also uploaded to virustotal a few tiny windows apps that come with FASM and, oh horrors, even those tiny "hello world"-style apps were flagged as malicious by a few engines.

I don't know exactly what's so suspicious about my compiler's output.
One thing I thought was simply poor, unoptimized code with too many memory accesses. Like something that could be automatically generated (duh, that's what compilers do!). But then the same problem would exist in the Linux and MacOS executables. Do those engines not check those other formats at all? Or are there too few viruses for Linux and MacOS?

I have yet to make a few more experiments. Like, compile with gcc but link with smlrl. I should also try Belard's TinyCC as well since it's about as crappy as my compiler in terms of optimization.

I also didn't rule out lack of imports from msvcrt.dll. It must not matter. But it may.

> I should also try Belard's TinyCC as well since it's about as
> crappy as my compiler in terms of optimization.

TinyCC is as good as OW above, not perfect though.

> I also didn't rule out lack of imports from msvcrt.dll. It must not matter.
> But it may.

Inclusion of some 50 dummy imports from msvcrt.dll moves the needle a tiny bit: from ...
to. Avast is still there with its suspicions.

> Avast is still there with its suspicions.

Found this: Report a false detection. Submitted the project URL. We'll see what happens.

> > > Actually, MS Security Essentials deleted my local .ZIP
> > while I was just listing the files in it! So I had to go to
> > "Settings" and add it to "Excluded files and locations".
> >
> > Um... I had the project directory excluded on my Windows 7 because it
> was
> > slowing things down, but I just removed the exclusion and scanned the
> > directory with Security Essentials and all was OK. The virus/malware
> > definitions were last updated yesterday (version 1.257.257.0). What's on
> > your end?
>
> I'm on the wrong machine right now, but I did update the definitions
> yesterday. But I'm not imagining this, it definitely deleted it, ugh. Even
> after having similar problems like this, it's still annoying.

I just downloaded the .zip file from github and Security Essentials did indeed immediately find it bad, very bad (naturally, the most innocent file, smlrc.exe is sad to have Trojan:Win32/Tiggre!rfn). And it wouldn't let me get the file out of quarantine (bug?).
But there's no problem if the contents of the .zip file are sitting unpacked on the disk. Manually directing Security Essentials to scan my github directory yields nothing. Go figure.

> I don't know exactly what's so suspicious about my compiler's output.
> One thing I thought was simply poor, unoptimized code with too many memory
> accesses. Like something that could be automatically generated (duh, that's
> what compilers do!). But then the same problem would exist in the Linux and
> MacOS executables. Do those engines not check those other formats at all?
> Or are there too few viruses for Linux and MacOS?

I highly doubt they do scan (much, if at all) other formats for other OSes. It's mostly a Windows problem.

Though "Reanalyze" shows ClamAV reporting "Osx.Malware.Agent-6370979-0". (Maybe I missed that before!)

>> Avast is still there with its suspicions.
>
> Found this: Report a false detection. Submitted the project URL.
> We'll see what happens.

I already reported the .ZIP to them, but maybe you think the URL would be more obvious?

Anyways, it now says "Avast : Clean" (on VirusTotal), but you're still getting 33/60 other false positives (most saying "generic", ugh).

Obviously you don't need my advice, but couldn't you split the Win32 .EXEs in half or something? Just make the end user recombine them. Heck, nop out the entire PE header, and add a plain text script to somehow recombine it. Heck, just .ZIP encrypt \binw\*.exe (like Japheth had to do with HX) with the password being (I don't know) "password". Put the password in the .ZIP comment (and/or readme), for full transparency.

Or not, I'm sure you don't need my ideas.

> > MacOS executables. Do those engines not check those other formats at
> all?
> > Or are there too few viruses for Linux and MacOS?
>
> I highly doubt they do scan (much, if at all) other formats for other OSes.
> It's mostly a Windows problem.
>
> Though "Reanalyze" shows ClamAV reporting "Osx.Malware.Agent-6370979-0".
> (Maybe I missed that before!)

I too did.

> >> Avast is still there with its suspicions.
> >
> > Found this: Report a false detection. Submitted the project URL.
> > We'll see what happens.
>
> I already reported the .ZIP to them, but maybe you think the URL would be
> more obvious?

Dunno. Just gave them the URL for the zip on github. They couldn't just scan by the project URL (can't traverse HTML?).

> Anyways, it now says "Avast : Clean" (on VirusTotal), but you're still
> getting 33/60 other false positives (most saying "generic", ugh).
>
> Obviously you don't need my advice, but couldn't you split the Win32 .EXEs
> in half or something? Just make the end user recombine them. Heck, nop out
> the entire PE header, and add a plain text script to somehow recombine it.
> Heck, just .ZIP encrypt binw*.exe (like Japheth had to do with HX) with the
> password being (I don't know) "password". Put the password in the .ZIP
> comment (and/or readme), for full transparency.
>
> Or not, I'm sure you don't need my ideas.

How about the two MZ chars stripped? Here's the link to download the project from the new experimental branch av. Follow the simple instructions in binw/combine.txt.

> How about the two MZ chars stripped? Here's [av.zip] the link to download
> the project from the new experimental branch av.
> Follow the simple instructions in binw/combine.txt.

Looks fine, no complaints.

> > How about the two MZ chars stripped? Here's [av.zip] the link to
> download
> > the project from the new experimental branch av.
> > Follow the simple instructions in binw/combine.txt.
>
> Looks fine, no complaints.

Cool! Merged into master (also moved combine.txt contents into readme.txt).

> > Also, it's probably a good idea to include the project wiki pages
> > into the package since there's no /? or --help option in the binaries
> > and somehow those wiki pages are not really part of the project
> > (you don't get them in the .zip file downloaded from gitHub
>
> Sounds tedious, but I'll try (maybe).

I've moved the documentation as markdown files (.md) from the wiki to v0100/doc, so one can get it together with the rest of the project whether by git-cloning or downloading the archive file off github. Better than nothing, IMO.

> I've moved the documentation as markdown files (.md) from the wiki to
> v0100/doc, so one can get it together with the rest of the project whether
> by git-cloning or downloading the archive file off github. Better than
> nothing, IMO.

Thanks! I'll definitely take a closer look.

<rant>

BTW, not to harp on it forever, but I wonder if these antiviruses ever test each other? Or if they test their own development tools? Surely that would be the first thing to do, to make sure they aren't compromised, right? What could go wrong?

</rant>

EDIT:

> And it wouldn't let me get the file out of quarantine (bug?).

Okay, just for full transparency, if you're morbidly curious ....

Firefox 57.0.1 (64-bit), Win7 ... I go to the Github page and click "Clone or Download". It does download, but the file is 0 bytes. In the download window, it has a red circle with a white line in the center. "This file contains a virus or malware." Which is annoying, obviously, since VirusTotal gives zero false positives anymore! So that means Firefox is somehow aware of the .ZIP's "checkered" past (pardon the ridiculousness) but is too dumb to know that it has improved.

Right click -> Allow Download brings up a message box that can't be switched away from. I can't minimize Firefox, nor can I switch tabs even (although of course I can run other programs). Title is "Are you sure you want to allow this download?", actual message is "This file contains a virus or other malware that will harm your computer.", "You can search for an alternate download source or try again later." [Allow download] [Cancel]

(Alternate source?? Try again later??? Does that even make practical sense????)

So I click allow, and it then shows up correctly as 1.6 MB .ZIP. I can do "unzip -Cpaa *.zip *binw/readme.txt", and it will display the text correctly.

Right click -> Clear Downloads. Pointless, but I always do this. It just clears the history ... except here it also deletes the .ZIP. ("Remove from history" also does this!) So, sadly, I have to rename or move the file first before it does that ... else I have to jump through all the hoops again! (Maybe they assumed no one would ever rightfully unblock a file.)

Maybe it's just a silly Firefox bug (which I will not waste my time reporting). But I've previously had (rare) "errors" like this in Chrome, too, for other innocent stuff. I understand that viruses are a problem, but at some point it's insane to be so error-prone in false positives.

I don't blame you, obviously, just saying it's a giant mess, and I don't even do or use anything sensitive.

EDIT #2: Using the URL to master.zip at VirusTotal does give me 2/66 false positives (while uploading the file itself doesn't).

> Include the project GitHub URL and the SHA of the top commit somewhere in
> the package description, so the package can be traced back if needed

Apparently the SHA of latest commit is included as main comment in .ZIP, so you can check via "unzip -z SmallerC-master.zip", which gives me this:

> Archive: SmallerC-master.zip
> 549e93389b9bbde8b87c4ad64fdfb757fbc7a880

Github says this (where "549e933" is a link):

> Latest commit 549e933 2 days ago

(click link)

> alexfru committed 2 days ago
> 1 parent 42644ea commit 549e93389b9bbde8b87c4ad64fdfb757fbc7a880

> <rant>
>
> BTW, not to harp on it forever, but I wonder if these antiviruses ever test
> each other? Or if they test their own development tools? Surely that would
> be the first thing to do, to make sure they aren't compromised, right?
> What could go wrong?
>
> </rant>

:)

> EDIT:
>
> > And it wouldn't let me get the file out of quarantine (bug?).
>
> Okay, just for full transparency, if you're morbidly curious ....
>
> Firefox 57.0.1 (64-bit), Win7 ... I go to the Github page and click "Clone
> or Download".

Chrome and IE don't like the zip file either, although some time ago Chrome either didn't complain about it or let me have the file (you may still have it, although it's not immediately obvious how (the file is downloaded but with the wrong/temporary name; you now need to click on "show all" to see the option for keeping the file, which, I guess, not everyone is smart enough to try)). Speaking of mass hallucinations, they're losing it.

> Maybe it's just a silly Firefox bug (which I will not waste my time
> reporting). But I've previously had (rare) "errors" like this in Chrome,
> too, for other innocent stuff. I understand that viruses are a problem, but
> at some point it's insane to be so error-prone in false positives.

I don't recall which browser did it, but it did once tell me something like "this file isn't downloaded often and may be dangerous". Great logic. Fear all of the unusual.

> I don't blame you, obviously, just saying it's a giant mess, and I don't
> even do or use anything sensitive.
>
> EDIT #2: Using the URL to master.zip at VirusTotal does give me 2/66 false
> positives (while uploading the file itself doesn't).

Same shitty experience as with Security Essentials. It doesn't find any harm in the executables on the disk, but the zip file with all those same files downloaded from the internet is somehow bad for ya. Gotta ban zip files!

> Apparently the SHA of latest commit is included as main comment in .ZIP

Handy.

> EDIT #2: Using the URL to master.zip at VirusTotal does give me 2/66 false
> positives (while uploading the file itself doesn't).

1/66 now.
https://www.virustotal.com/#/url/c08ad8ccf56624f6d...710385a5e50ccaab91eac5a5e0988fb4ac573/detection

> > I've moved the documentation as markdown files (.md) from the wiki to
> > v0100/doc, so one can get it together with the rest of the project
> whether
> > by git-cloning or downloading the archive file off github. Better than
> > nothing, IMO.
>
> Thanks! I'll definitely take a closer look.

I also made most of the text in the .md files fit a 80-column screen.

I guess that would make things readier(?) for a package. What's the plan, if any? Looks like github's .zip is slightly bigger than the 1.44MB floppy. Take binl and binm out and all should fit. Not sure if anyone's actually gonna use a real floppy and maybe a real 386 PC. :)

> I also made most of the text in the .md files fit a 80-column screen.
>
> I guess that would make things readier(?) for a package. What's the plan,
> if any?

No huge plans. Sorry, I'm just slow and prone to procrastination. I do still wish to make a .ZIP, though.

> Looks like github's .zip is slightly bigger than the 1.44MB floppy.
> Take binl and binm out and all should fit.

I would omit all binaries (including binw/) except bind/ and bindp/. But of course leave everything else (so it can still Canadian cross-build or whatever).

> Not sure if anyone's actually gonna use a real floppy and maybe a real 386 PC. :)

You'd be surprised. Many 486 users came out of the woodshed for FreeDOS 1.2. And people still build retro PCs, too. Then again, floppies are rarely relied upon. Most such users still use bootable CDs.

But no, normally, FreeDOS isn't stuck to floppies only. FDNPKG is the network-aware package manager, and FDINST is the optional offline installer. So these .ZIPs are just slightly arranged in a special way to facilitate simple package management. Oh, there's also FDI and FDIMPLES (and auto-updated webpages like Development which I already linked you to).

So yeah, I anticipate that potential FreeDOS users will grab this via FDNPKG for their hard disks (and/or virtual machines).

(I just got this email. FYI, I quote it below.)

Subject: False positive file SmallerC.zip Request #05551922 ref:_00Db0Z3Sf._500b01K6GXz:ref
From: support@help2.avast.nospam

> Hello,
>
> Thank you for reporting this false positive.
>
> Our virus specialists have now cleared its reputation in our database.
>
> With URLs this change should be instant, but it might take up to 24 hours with files.
>
> For future reference you might also find the following article to be useful: Avast Clean Guidelines.
>
>
> Best regards,
>
> Avast Customer Care