-1

EDIT to show a difference from this:

This question is specifically about solving the "unresolved external symbol(s)" by making modifications to the project using the interface for Visual Studio 2017. It is aimed towards those who do not have the necessity to write C++ code on a regular basis and therefore are not concerned with the nuances of how C++ compiling works.

TL;DR - This serves to provide a concise solution to the issue of linking libraries with the VS2017 interface without bringing any attention to the nuances of unresolved symbols. The solution is at the bottom.

I'm taking a malware-reverse engineering course and the following function call is giving VS2017 some trouble linking.

handle_t iOpenH = InternetOpen(L"Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) totally not Malware",
INTERNET_OPEN_TYPE_PRECONFIG,
NULL,
NULL,
0);

The errors:

Severity    Code    Description                                       Project           File                                                         

Error      LNK1120  1 unresolved externals                              fake-malware    C:\Users\darrel\Documents\school\Spring 2018\COMP 220 - Software Rev Eng\Lab4\Lab4_Win32_API\Release\fake-malware.exe   line: 1 
Error      LNK2001  unresolved external symbol __imp__InternetOpenW@20  fake-malware    C:\Users\darrel\Documents\school\Spring 2018\COMP 220 - Software Rev Eng\Lab4\Lab4_Win32_API\fake-malware.obj           line: 1

I've already cleaned and rebuilt to no avail. What should I do to resolve the two errors above?

EDIT 2: I just realized that the inherent meaning of the answers here are simple but not something that I was previously aware of having little experience with this sort of development, so I'll state it here in case you don't want to follow the link from @Anders below to remedy this problem:

When you use a library such as the Win32 API, you not only have to do the standard #include <headerName.h>, but the linker may require a .lib for the respective included library. In the instance we're working with wininet. Therefore, as mentioned in a table within the link from the comment below, the header include is #include <wininet.h> and the linker requires you to add wininet.lib to the Linker's list of Additional Dependencies:

SOLUTION

Project > Proerties > Configuration Properties > Linker > Input > Additional Dependencies > add the necessary .lib filename to the list.

Darrel Holt
  • 870
  • 1
  • 15
  • 39
  • 3
    [The documentation](https://msdn.microsoft.com/en-us/library/windows/desktop/aa385096.aspx) tells you that you are supposed to link with `Wininet.lib` – Igor Tandetnik Feb 23 '18 at 02:50
  • 1
    Downvoted because *"this question does not show any research effort"*. This question keeps getting asked, and a canonical answer has been available for **years**. – IInspectable Feb 23 '18 at 09:15
  • @IInspectable This isn't a duplicate because your link goes into much more depth than is necessary for someone that doesn't write C++ often. As I added above, this serves only so solve the issue in a timely fashion with no attention paid to the inner-workings of the C++ compiler. Furthermore, I did do research but didn't find a solution to my issue because it needs to be resolved *only* with VS2017, no custom compiler, external tools, etc. I saw "link the libraries" in some places, but they didn't relate to VS2017; see the tags, VS2017 has been there the whole time. – Darrel Holt Feb 23 '18 at 17:29
  • [Does Visual Studio Rot the Mind?](http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html) – IInspectable Feb 23 '18 at 17:45
  • Besides, [this answer](https://stackoverflow.com/a/12574400/1889329) (from the duplicate) even explains how to link against libraries using Visual Studio. This question **is** a duplicate. Being too lazy to read doesn't invalidate that. – IInspectable Feb 23 '18 at 17:47
  • @IInspectable Thanks for the interesting link. It does rot the mind, It's a big clunky piece of garbage that separates the user from fundamentals that matter, but it can be useful for getting certain things done quickly. Either way though, I prefer code::blocks for C/C++. – Darrel Holt Feb 23 '18 at 17:48
  • @IInspectable Pretty to find the answer when you know exactly what you're looking for, isn't it? – Darrel Holt Feb 23 '18 at 17:50
  • I see, again too lazy to read. The essence of the link applies to Code::Blocks just as well. But maybe you now understand, why people don't comment when they down-vote. Thanks for reminding me to stop commenting. – IInspectable Feb 23 '18 at 17:51
  • It's the **very** **first** link from the [summary](https://stackoverflow.com/a/12573818/1889329https://stackoverflow.com/a/12573818/1889329), that takes you there. You don't have to know anything to follow, what appears to be the most common reason. Regardless, this place is for professionals. Students that don't want to learn any more than absolutely necessary to pass the next test are not the intended audience. – IInspectable Feb 23 '18 at 17:53
  • @IInspectable I didn't say it didn't apply to C::B, I said I prefer it because it's simpler. This place is not exclusively for professionals, hence the 'homework' tag that used to exist and a great abundance of questions that are obviously homework. Also, I've seen plenty of professionals come here because they don't want to learn more than what is absolutely necessary to get their project finished. I didn't come here for answers to a homework problem. I came for help with something so that I can go find my own answers to my REAL problems. – Darrel Holt Feb 23 '18 at 18:05

1 Answers1

3

Make sure you are linking to Wininet.lib.

Add it to your project settings or add #pragma comment(lib,"Wininet.lib") to one of your source files.

Anders
  • 97,548
  • 12
  • 110
  • 164