[RESOLVED] Windows 10 and vbNewLine

Is there any issue with using vbNewLine on Windows 10 technical preview?

I've written a utility for an online game meant for wide distribution, so opted for pure VB6 to give the widest compatibility. So far so good: Everyone and their brother can download and run it without issue, no installation needed for anyone. Just unzip and double-click the exe.

The one issue I've run across is that the output seems to add a bunch of extra blank lines for someone who is using the Windows 10 technical preview. I'm just wondering if maybe it handles vbNewLine differently and I should switch to vbCrLf?

The program is a character planner for Dungeons and Dragons Online, and the output is created by adding each line to a string array and then combining them at the end with Join(array, vbNewLine). Speed was a consideration, and that seemed faster than a long series of concatenations.

EDIT: You can see the "finished" program here, with sample correct output in post #2. A sample of the bugged Windows 10 output can be seen here. The problem only seems to occur when there are multiple blank lines right after each other, in which case extras get added.

I'm happy to provide a download for the complete source code if requested. I plan to post it anyway, but was hoping to wait until I got to a stable version 1.0 before posting it.

If the Join method is implemented via a Windows API call then it is possible for it to be bugged on Windows 10. I can't say for sure if it is indeed implemented via a Win32 API call so I would suggest you work around it for the time being. You know the condition that causes the glitch so you're pretty much set.

Hi Ellis. vbNewLine is environment-specific, while vbCrLf always provides a carriage return + linefeed. Note also that some commands automatically append a newline character (e.g. "Print"), so you may need to account for that as well.

vbNewLine normally doesn't deviate from vbCrLf, but in the thread you linked, I noticed some guys were running the program on OSX or Linux via Wine. Just in case, you may want to switch to vbCrLf to prevent the possibility of unexpected behavior on those platforms.

(I know this doesn't answer your question, but maybe helpful??)

Great idea for a program, btw, and I second the comment from guys in the other forum to stick your work on GitHub. Seems like a perfect project for it. Nice work!

Quote:

---

Originally Posted by Tanner_H

I noticed some guys were running the program on OSX or Linux via Wine. Just in case, you may want to switch to vbCrLf to prevent the possibility of unexpected behavior on those platforms.

---

Regardless of any Windows 10 issues, this is excellent advice. Thanks much for pointing it out.

Seems very unlikely that an emualtor is going to change the insides of the VB6 runtime. Plus vbCrLf is slower than vbNewLine. They only differ in Mac and OS X Office VBA anyway.

Classic case of looking where the light is good.

Wine = Wine Is Not (an) Emulator. ;) It's a compatibility layer, which sounds like semantics but is actually an important difference. Because its goal is not to replicate Windows exactly, you can get unexpected differences, and the variety of Linux distros doesn't help.

The .NET equivalent of vbNewLine (Environment.NewLine) does use separate characters on different OSes, at least via Mono, which is what made me consider this. Still probably a shot in the dark, but the performance difference is close enough to be meaningless, so IMO no harm in switching to CrLf.

I'm not sure I'd want to make changes against Windows 10 anyway, since its behavior could change with the next TP.

In any case I'd like to hear where the newlines "appear" altered (TextBox? Written to disk?, Console output?) because if we need to deal with this in the RTM version a heads-up would be great.

They appear in the textbox.

I designed it so that the output is sent to the textbox, then the user can click a button to copy the textbox contents to the clipboard, which they can then paste to a forum thread. This allows last-minute manual changes to the output while still supporting the "Copy to Clipboard" button.

The WinX guy reports that he sees the extra blank lines in the textbox.

EDIT: It may be worth pointing out that I do use the Print command to send a copy of the output to a picturebox on the main form. This is not related to the output the user can send; I had to handle the Print commands differently in order to support [List][/List] BBCode tags. The Print commands print each line as they go, no Join() at all.

The WinX guy sent me a screenshot of his main form, and the Print commands do not add the extra blank lines.

whether it has any bearing on the matter, there do not appear to be any carriage returns in either of the linked outputs, only line feeds

Changed from vbNewLine to vbCrLf, but apparently no joy.

The WinX user is up for testing, so I'll put together some test programs to email him to try and pinpoint the problem. Any suggestions for what to include in such test programs welcome.

check the textbox content for the extra crlf

Quote:

---

Originally Posted by Tanner_H

vbNewLine normally doesn't deviate from vbCrLf, but in the thread you linked, I noticed some guys were running the program on OSX or Linux via Wine. Just in case, you may want to switch to vbCrLf to prevent the possibility of unexpected behavior on those platforms.

---

There is a slight possibility for incompatibility if the guys in this other thread were *compiling* the application in question, not simply running it. You do realize that once compiled vbNewLine (and any other typelib defined constant) gets "embedded" in the executable. It's not possible for WINE to change the constant in compiled binaries.

On the other hand, VBA code being interpreted on different OSes can experience constants difference.

@OP: Do you by chance compile the app to p-code? *That* would be even weirder practice.

cheers,
</wqw>

No P-Code, no.

My understanding is that Wine couldn't even run P-Code.

Quote:

---

Originally Posted by Ellis Dee

No P-Code, no.

My understanding is that Wine couldn't even run P-Code.

---

Wine can run P-Code as well.

P-Code is "native-x86-code-in-PE-format" too, just that nearly each atomic Operation
is calling into the vbRuntime (and the runtime needs to be installed on Wine in both cases).

Olaf

Quote:

---

Originally Posted by wqweto

You do realize that once compiled vbNewLine (and any other typelib defined constant) gets "embedded" in the executable. It's not possible for WINE to change the constant in compiled binaries.

---

By definition, an environment-specific constant would need to be resolved at run-time, no? I would think it's similar to other "pseudo-constants" like system colors (vbButtonFace, etc), which are evaluated to a usable value at run-time. (Of course, system colors have a known function that converts the magic number constant to an actual, usable value. I don't know what the equivalent would be for vbNewLine; if it's a function implemented by Windows, WINE might re-implement it differently, hence my original suggestion.)

At any rate, I'll look at installing the Windows 10 TP today. As dilettante said, if this is something specific to Windows 10, it would be nice to know.

Ellis, I think this was a red herring.

I just tested your program (version 0.9.4) on Windows 10 in a VM (Build 9926) and the output was identical to Windows 7, and your "good" example link above. There were no duplicate line-endings. Copy+pasting into Notepad also shows no line-ending issues.

My guess? The problematic line-endings were a browser issue, caused when the user pasted the text into the forum webpage. (If the user was using IE on Windows 10, that wouldn't be surprising - I've only used it for a few minutes and it's all kinds of buggy.)

I tested some other VB projects on Windows 10 and also found no issues with line-endings, so I don't think this is an OS-level problem.

Quote:

---

Originally Posted by Tanner_H

By definition, an environment-specific constant would need to be resolved at run-time, no? I would think it's similar to other "pseudo-constants" like system colors (vbButtonFace, etc), which are evaluated to a usable value at run-time.

---

No, I don't think so.

In anything I have ever read anywhere vbNewLine is always a "fast" CRLF (for some reason vbCrLf was implemented differently) with only two exceptions: VBA in Office for Apple OSs and VBScript in IE for Apple OSs.

But it is good to know this entire thread was probably a red herring anyway.

Quote:

---

Originally Posted by dilettante

No, I don't think so.

In anything I have ever read anywhere vbNewLine is always a "fast" CRLF (for some reason vbCrLf was implemented differently) with only two exceptions: VBA in Office for Apple OSs and VBScript in IE for Apple OSs.

---

I've never really understood the implementation differences between VBA and VBRUN constants, but the specific call-out of "platform specific" in the vbNewLine description always seemed odd. The performance difference between vbNewLine and vbCrLf makes it even stranger.

I don't suppose anyone has ever looked at the actual compiled ASM to see how they are actually implemented, rather than hazarding guesses...? (I'd try, but ASM isn't exactly my wheelhouse :( )

I found this
vbCrLf = "\n" # Carriage returnlinefeed combination
vbCr = chr(13) # Carriage return character
vbLf = chr(10) # Linefeed character
vbNewLine = "\n" # Platform-specific new line character; whichever is appropriate for current platform

here: http://www.developerfusion.com/threa...ine-feed-chars

Which jives with what I seem to remember.

I don't recall ever having any major issues with vbCRLF as far as performance goes, but then I've never bothered to look into it either. The only think I can think that might cause vbCRLF to have performance issues is due to it's combining two bytes togeher, while the vbNewLine likely uses some kind of API to query the system for the new line character(s) and simply passes through the value, and there's not combining/concatenation going on.

It's all conjecture. Although I suspect that performance is less of an issue and the actual returned output is what's critical here.

I'm not convinced there's a red herring here either, although I'd suspect if there really was a problem, it would be more prevalent. @ED - any idea, besides the problem client, how many, if any, others are running Win10, and are they also having the same problem? (and maybe not reporting it?)

If it's just the one, and there are others with Win10 that are not having a problem, then yeah, you probably have a one-off case that's a red herring and not much you can do about it. But if the problem is more prevalent than you know...

-tg

No way to know how many have Win10, but in terms of the MediaFire downloads, the various versions have been downloaded around 400 times each. I've only heard from maybe a couple dozen people, so who knows how many are having issues.

Great to hear that it does work properly on at least one Win10 system; that's a huge relief. I'll leave this thread unresolved for a little longer while I try to figure out the issue with the guy having the problem.

EDIT: And I'm switching back to vbNewLine just because I like it better. heh.

Quote:

---

Originally Posted by Tanner_H

I don't suppose anyone has ever looked at the actual compiled ASM to see how they are actually implemented, rather than hazarding guesses...? (I'd try, but ASM isn't exactly my wheelhouse :( )

---

Just fire oleview.exe and File->View typelib of C:\Windows\SysWOW64\msvbvm60.dll (or whatever navigating to parent typelib in object explorer shows) and locate vbNewLine

Code:

---

    // NOTE: This module has no entry points. There is no way to
    //      extract the dllname of a module with no entry points!
    //
    [
      dllname("<no entry points>"),
      uuid(343DB180-2BCC-1069-82D4-00DD010EDFAA),
      helpcontext(0x000f6ebd)
    ]
    module Constants {
        [helpcontext(0x000f79aa)] const long vbObjectError = 0x80040000;
        [helpcontext(0x0010aa32)] const LPSTR vbNullString = "";
        [helpcontext(0x0010aa32)] const LPSTR vbNullChar = "\0";
        [helpcontext(0x0010aa32)] const LPSTR vbCrLf = "\r\n";
        [helpcontext(0x0010aa32)] const LPSTR vbNewLine = "\r\n";
        [helpcontext(0x0010aa32)] const LPSTR vbCr = "\r";
        [helpcontext(0x0010aa32)] const LPSTR vbLf = "\n";
        [helpcontext(0x0010aa32)] const LPSTR vbBack = "\b";
        [helpcontext(0x0010aa32)] const LPSTR vbFormFeed = "\f";
        [helpcontext(0x0010aa32)] const LPSTR vbTab = "\t";
        [helpcontext(0x0010aa32)] const LPSTR vbVerticalTab = "\v";
    };

---

All typelib constants (and imports) are "embedded" in the final executable, these are not consulted at run-time so that you can omit shipping the typelib on client machines and there is no way to make vbNewLine platform specific once it is compiled in the executable. Every other implementation option would allow a malicious user to inject whatever strings she would want in your final executable -- not very secure.

cheers,
</wqw>

To add to that...
The platform-specific differences (of the Char-contents of the vbNewLine-Constant) -
are then ensured over platform-secific *compiles* of an appropriate Runtime-Lib, so that
e.g. on a Mac which runs "Office-VBA", vbNewLine will be "hardwired" to only "\r"...

As for ensuring a higher Wine-Compatibility - I've always overriden the Wine-internal oleaut32.dll
(sitting in: .../drive_c/windows/system32/.) with a "native one" (gathered from the appropriate
System-Folder on XP or Win7) - and we are allowed to do that, since OleAut32.dll is mentioned
in redist.txt.

To do that properly, one can place the native OleAut32.dll (with e.g. this camel-case notation)
directly beside Wines oleaut32.dll in Wines system32-Folder without any problems (since the
Linux-FileSystems are case-sensitive and allow that)...
Then the most comfortable way, to switch from "builtin" (Wine-OleAut32) to the native one
(which is physicall already there in /system32/) - one can startup (at a Linux-Console):

Code:

---

winecfg

---

and in the up-popping Dialogue change the Dll-Override for oleaut32 from "builtin" to "native".

That's it already - that helped me with ADO-stuff, as well as with all kind of Variant- and
SafeArray-stuff, which didn't always work *exactly* as tested on native Windows- but
after the override it did...

Olaf

That still leaves the question of performance differences between use of vbCrLf vs. vbNewLine. It can't all be imagination though since it is quite widely cited as real.

But of course things might have changed along the way from VB6 RTM to SP6x. I'm stubborn enough to use vbCrLf myself whenever I am doing something like formatting raw HTTP and other RFC'd protocols, but vbNewLine everywhere else. I prefer the source code to reflect what I intend.

Quote:

---

Originally Posted by dilettante

That still leaves the question of performance differences between use of vbCrLf vs. vbNewLine. It can't all be imagination though since it is quite widely cited as real.

---

Against myths there's a cure, called "own observation" (and as developers, we prefer code for that)...

Here's some simple test-code I knocked together (took me about 1 minute, and I guess that
was far faster than googling for things "quite widely cited").

Code:

---

Private Sub Form_Click()
Dim i&, T!, S$
Const n& = 40 * 10 ^ 6 '40Mio rounds

  AutoRedraw = True

  T = Timer
    For i = 1 To n
      S = CStr(i) & vbNewLine
    Next
  Print "Concats with vbNewLine:", Timer - T
 
  Refresh
  DoEvents
 
  T = Timer
    For i = 1 To n
      S = CStr(i) & vbCrLf
    Next
  Print "Same concats with vbCrLf:", Timer - T
End Sub

---

ScreenShot, after compiling it natively (all extended options, leaving out only the first one -
though in the IDE there's no larger difference):

http://vbRichClient.com/Downloads/vb..._vs_vbCrLf.png

Olaf

Quote:

---

Originally Posted by dilettante

That still leaves the question of performance differences between use of vbCrLf vs. vbNewLine.

---

Never heard of it. And probably that is why I never experienced any performance issues with these constants.

Could this be a local vbForums myth, me being a recent lurker here?

cheers,
</wqw>

There is also no difference when using a variable instead of a predefined constant:

Code:

---

Option Explicit

Private Const CRLF As String = "CL" ' pseudo delimiter

Private Sub Form_Click()
  Dim i&, T!, S$
  Dim sCrLf As String
 
  Const n& = 40 * 10 ^ 6 '40Mio rounds

  sCrLf = Chr$(10) & Chr$(13)
  AutoRedraw = True

  T = Timer
    For i = 1 To n
      S = CStr(i) & vbNewLine
    Next
  Print "Concats with vbNewLine:", Timer - T
 
  Refresh
  DoEvents
 
  T = Timer
    For i = 1 To n
      S = CStr(i) & vbCrLf
    Next
  Print "Same concats with vbCrLf:", Timer - T

  Refresh
  DoEvents
 
  T = Timer
    For i = 1 To n
      S = CStr(i) & sCrLf
    Next
  Print "Same concats with variable:", Timer - T

  Refresh
  DoEvents
 
  T = Timer
    For i = 1 To n
      S = CStr(i) & CRLF
    Next
  Print "Concats with constant:", Timer - T

End Sub

---

Can this thread be marked with [BUSTED] now :-))

cheers,
</wqw>

One source that is generally fairly reliable is Optimize string handling in VB6 - Part I:

Quote:

---

For some reason, vbNewline is a little bit faster than vbCrLf.

---

I can't say whether this (a.) used to be true perhaps in VB5, (b.) used to be true perhaps in early VB6 prior to some Service Pack, or (c.) never was true but their own profiling tools somehow gave false results.

I ran a test using their profiler, and in default mode it did show vbNewLine to be faster by a hair. However using their "alternate" mode there was no difference (VB6 SP6).

Yeah, I'm going to mark this RESOLVED since the guy experiencing the problem emailed me the text file output created by the program, and there's nothing different about his text file than when I generate one on Windows 7. I'm thinking he has a browser issue wholly unrelated to my program.