|
Last October I submitted a bug report [^] and made several comments elaborating on the problem. It has to do with the FileVersionInfo family of API functions and how the their build process is broken because programs are linked to the wrong libraries which don't contain the relevant functions. There have been several updates since then and I install them all and the problem hasn't been fixed yet.
I had actually written this off as yet another Microsoft-ism but I noticed they finally replied to my report :
"Thank you for your feedback. We have determined that this issue belongs to the Windows platform. Please provide feedback using Windows 10 feedback hub store app. For more information, see https://support.microsoft.com/en-us/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app"
What the ...? this is most definitely NOT a platform problem. It is a problem with their linker configuration because VS207 links my programs with the wrong libraries which are either not present or do not contain those functions. There is no work-around available other than not using those functions so I have to implement similar functionality myself in a different way.
This is really getting tiresome. I am not sure I want to bother reporting the other issues I have run into. One is very annoying because it requires that we install the redistributable package. I wanted to use static linking but that is not an option.
-edit- because of this problem, I can't use the statically linked version.  /edit
BTW - the problem is still present in today's 15.9.9 update. I tried it and that attempt inspired this rant.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
modified 12-Mar-19 16:39pm.
|
|
|
|
|
Rick York wrote: today's 15.9.9 update
Another one? We just had 15.9.8 last week.
I see the download for this update is "only" 1.4 Gb. I hate to think how anyone who doesn't have unlimited fibre broadband copes with this nonsense.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I have had grief with that site too.
At one point they told me that the thing that I saw happen in Visual Studio 2017 was not happening...
even though I had provided them with exact screenhots of the issue. Others had posted the same problem and confirmed.
The issue was finally resolved just because it happened to be fixed in the next release anyways, but it was annoying.
Rick York wrote: I am not sure I want to bother reporting the other issues I have run into.
That is the exact same effect it had on me. Since they just say, "oh, yeah, whatever..." and don't even bother to say, "ok, we'll look into this, it looks like something" it just ends up annoying you more really.
I really don't like when these type of forums turn into that. StackOverflow/StackExchange sites often turn into this and so it teaches you to only be a "reader" and never a "reporter" which is really unfortunate.
Especially in cases like yours - I read your reports and they contain very useful info that someone could take action on if they wanted to. But no. 
|
|
|
|
|
|
Thanks for the reinforcement. I was hoping I didn't come across as just another ranting fool.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Honestly, I'm surprised the issue wasn't pawned off on the XBox App or Notepad developers; had an MSI issue with a "game" installer in the past and it was blamed on the XBox devs even though the game specifically targeted Windows having nothing to do with XBox anything.
Feedback Hub & Insider programs need better filtration for isolation and then passed on rather than the inferred "the buck stops here" reporting services, front-end, desk jockey, cavalcade it persist to appear as.
Had a few instances of error reporting sickness myself, so can relate unfortunately.
Might explain why Microsoft was soliciting for "Insiders" previously as many have probably, like myself, decided to move on to other areas in our existence rather than awaiting canned answers or finger pointing placing blame on someone else's department. Blame != Professionalism (default) --there are exceptions to the rule, but generally (in the case of Windows error and feedback reporting) not too many.
I was unaware of that...
|
|
|
|
|
Hi,
I can explain why it's a Windows Platform issue. It's the OSG (Operating Systems Group) that determines which functions are exported from mincore. When I was working on the OneCore SKU now called "Windows Core OS" it would take several weeks/months and a vetting process to get any functions added to mincore.
I'd recommend following up and posting on the feedback hub. Maybe you can have @Richard-MacCutchan also give some feedback. He complained about the same issue. I believe they are using a weighting algorithm based on how many people complain about the same thing over at feedback hub.
Best Wishes,
-David Delaune
|
|
|
|
|
I can understand why that would be the case. I don't think that's really the problem though. I haven't tracked down the various DLLs and checked their exports to see where the functions actually are but the fact is I shouldn't have to. The documents say link with mincore.lib so I do that and the app links. However, when it runs it can't find the DLL it is supposed to import the functions from as I have explained. This means the linking process is messed up and I don't feel like doing their work to sort it out for them. It seems to me they should be able to just change where the functions are imported from as part of linking with that library because the missing DLL is explicitly imported by the app.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: It seems to me they should be able to just change where the functions are imported from as part of linking with that library because the missing DLL is explicitly imported by the app.
No, the compiler group consumes mincore.lib generated by the operating system build. Not the other way around. I can see why this might be confusing to someone on the outside.
You should just post something regarding the problem onto the feedback hub so the correct team gets visibility into your issue.
Best Wishes,
-David Delaune
|
|
|
|
|
Rick York wrote: VS207
You have the wrong version mate!
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
|
Tell them it's preventing you from seeing one of the new icons. They'll fix it right away.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Great idea!
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Dude, I've been waiting for a couple of bugs to be fixed in FORMAT and FDISK since, oh, let's see now, .... ah, 1991!
Still waiting.
|
|
|
|
|
beuz u can
The best way to improve Windows is run it on a Mac.
The best way to bring a Mac to its knees is to run Windows on it.
~ my brother Jeff
|
|
|
|
|
so u are telling that they did not fix dll hell ...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
They sort of did fix that but they are finding different ways to break things.
Another thing - when I link with static libraries then my apps can't load resources from the libraries so several of the built-in controls won't work. The hits just keep on coming.
The most annoying thing is the fingers are pointed at someone else and there is no way (I have found) to inform the target of those fingers. This means the likelihood of the issues being fixed is minimal.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Today, I encountered a problem that appeared to suggest that stringizing behaves differently when headers are fed to the Win32 Resource Compiler, rc.exe. My research led me to a post by Raymond Chen, The Resource Compiler’s preprocessor is not the same as the C preprocessor – The Old New Thing, which included the following comment posted by laonianren at October 5, 2017 at 5:26 am:
Stringizing can be persuaded to work in rc files. This converts version numbers into a dotted string suitable for the text part of a version resource:
#define STRINGIZE(x) #x
#define EXPAND(x) STRINGIZE(x)
#define MAJOR_VERSION 10
#define MINOR_VERSION 0
#define RELEASE_NUMBER 14393
#define BUILD_NUMBER 0
#define DOTTED_VERSION EXPAND(MAJOR_VERSION) "." EXPAND(MINOR_VERSION) "." EXPAND(RELEASE_NUMBER) "." EXPAND(BUILD_NUMBER)
I ultimately discovered that the workaround described above is not only no longer needed, but actually won't work, because the EXPAND directive used therein is no longer recognized. With the current tools, you can do this.
#define VER_DESCRIPTION_AND_PLATFORM VER_FILE_DESCRIPTION VER_PLATFORM
Though this improvement may be buried in a changelog, it's just as likely that it was quietly fixed, but never reported.
The bottom line is that it opens some very cool possibilities, such as incorporating variable text that depends on preprocessor values in standard version resources.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
It was interesting to read Raymond's blog on this. Someone asked me the other day about my style of include guards and my reply was I've been doing it this way for so long I don't remember exactly why. That blog posted reminded me - I didn't have a compiler that supported pragmas back then it was quite a while until "pragma once" existed.
FWIW, this is what I do :
#ifndef HEADER_H
#define HEADER_H
#else
#error repeated include of this file
#endif
and I ALWAYS have the little commented section so I can copy and paste it and I am always safe. I did this back in the days when a global file change resulted in a compile and build process that took about forty minutes for our system. I cut that down by two thirds by putting this into the headers and I still do it today. I actually got the idea from Microsoft's headers and added the error statement to let me know of offenders. Microsoft still does this today, minus the error. Have a look at afxwin.h for an example.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I think that this is programming, so I{ll read something else in the Lounge.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
The new way to make a ListView in Android apps is to use the RecyclerView.
It's quite a complex thing, just to create a ListView.
You will have to create an Adapter class based off your Model type (in my case and the example below that Model type is called Entry -- think JournalEntry).
The Adapter you create will contain a list of your Model :
List<Entry> allEntries;
But, here is where it starts getting weird:
Your EntryAdapter has to extend A RecyclerView.Adapter of EntryAdapter.Viewholder :
So your class definition will look like the following:
public class EntryAdapter extends RecyclerView.Adapter<EntryAdapter.ViewHolder>
It Gets Weirder
And it gets weirder (to me).
That Generic type (RecyclerView.Adapter) expects that your EntryAdapter contains a class named ViewHolder and EntryAdapter.ViewHolder extends RecyclerView.ViewHolder.
So here is just the basic outline of your EntryAdapter:
public class EntryAdapter extends RecyclerView.Adapter<EntryAdapter.ViewHolder>{
public List<Entry> allEntries;
public EntryAdapter() {
}
public EntryAdapter(List<Entry> entryList) {
allEntries = entryList;
}
public class ViewHolder extends RecyclerView.ViewHolder {
}
}
My Head Explodes
For me, my head kind of explodes on all of that.
The entire reason you need to do all of that is because you need to override a method and implement a couple of methods from the Generic RecyclerView.Adapter.
So really, your basic class will look like the following
public class EntryAdapter extends RecyclerView.Adapter<EntryAdapter.ViewHolder>{
public List<Entry> allEntries;
public EntryAdapter() {
}
public EntryAdapter(List<Entry> entryList) {
allEntries = entryList;
}
public EntryAdapter.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
}
@Override
public void onBindViewHolder(EntryAdapter.ViewHolder holder, int position) {
}
public int getItemCount() {
}
public class ViewHolder extends RecyclerView.ViewHolder {
}
}
A Few of Things That Stand Out
1. This really is the new expected way to simply create listview type of items in the Android dev world. The ListView type is being deprecated.
2. Generic / template type syntax is always difficult to read.
Here's my natural language reading of my EntryAdapter type:
I have an EntryAdapter that is a RecyclerView adapter of EntryAdapter viewholder. 
3. This kind of thing makes it kind of difficult to talk about the types and the code and ends up causing me just to memorize all of this. Maybe that is good but it's quite an extensive pattern just to get to a listview of items.
My brain hurts. But I did get it working at least.
|
|
|
|
|
That's not too bad as far as infrastructure support goes. If you want a real nightmare, have a look at the Zend Framework someday. It will test your sanity.
I haven't written Java in years, but can you not define a generic version of the Adapter?
public class ModelAdapter<T> extends RecyclerView.Adapter<ModelAdapter<T>.ViewHolder>{
public List<T> allItems;
...
}
Or are the needs of that overriden method too specific?
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Nathan Minier wrote: but can you not define a generic version of the Adapter?
I'm not sure. But since I'm digging through this myself what would that do for me?
Are you thinking of creating a generic one that handles multiple types, maybe?
I think the only reason this is genericized is because it is an attempt to provide a generic way to bind model elements to the view and since those end up being specific fields then you have to (at this point) give it a specific implementation that you want to bind.
Anyways, I think that is the point.
Thanks for chiming in on the discussion. 
|
|
|
|
|
That almost sounds like a programming discussion in the Lounge.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Walt Fair, Jr. wrote: That almost sounds like a programming discussion in the Lounge.
Is this sentence stating your shock?
A programming discussion in the lounge!!! What!?! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
